question

Upvotes
Accepted

IP receives multiple close requests on same RIC

Hi,

We have a couple of old IP's which use SSL and those are now due to be replaced with RSSL driven IP's.

We noticed a strange behavior with the new RSSL IP's when requesting RIC's via either Eikon or a Reuters SDK/Script. Basically what happens is that if you request a RIC, let's call it RIC1. I can see us receiving the request in our IP, we respond to it and I get values back in our requesting application.


If I close the socket, I can see our IP receiving a close request. So far so good.

Now if I request anything, RIC2, RIC3, or RIC1 again, the TREP will only keep sending close requests for RIC1.


Here are some logs to show this behavior.


Client requests and receives response

Connecting to market data server

Subscribing to market data for EUR/USD

----------------------------------

Refresh message, item Handle: 7577440 Closure: 0

Item Name: EUR/USD

Service Name: TBID-DEV

Item State: Open / Ok / None / 'Refresh Completed'

Fid: 22 Name: BID DataType: Real Value: 1.16416

Fid: 25 Name: ASK DataType: Real Value: 1.16478

Fid: 30 Name: BIDSIZE DataType: Real Value: 2e+07

Fid: 31 Name: ASKSIZE DataType: Real Value: 2e+07

Here is the same request in our IP

15:54:29.553 Status Got market price request: ReqMsg

streamId="1881"

domain="MarketPrice Domain"

InitialImage

InterestAfterRefresh

ConflatedInUpdates

priorityClass="1" priorityCount="1"

qosRate="TickByTick"qosTimeliness="RealTime"

name="EUR/USD"

nameType="1"

serviceId="1"

serviceName="TBID-DEV"

ReqMsgEnd

, handle: 140734437190848


We kill the client subscription, and this is what our IP receives.

15:54:33.907 Status Got close request: ReqMsg

streamId="1881"

domain="MarketPrice Domain"

name="EUR/USD"

nameType="1"

serviceId="1"

serviceName="TBID-DEV"

ReqMsgEnd

, handle: 140734437190848


We request the same RIC again, and this is what our IP receives

15:54:39.562 Status Got close request: ReqMsg

streamId="1881"

domain="MarketPrice Domain"

name="EUR/USD"

nameType="1"

serviceId="1"

serviceName="TBID-DEV"

ReqMsgEnd

, handle: 140734437190848


This is what our client receives in this scenario

Connecting to market data server

Subscribing to market data for EUR/USD

Status message

Item Name: EUR/USD, Service Name: TBID-DEV

Stream state: 1 Status code: Status text: Request timed out.

Status message

Item Name: EUR/USD, Service Name: TBID-DEV

Stream state: 1 Status code: Status text: F49: Item is pending close. Please retry



Any help on what can be the cause of this is appreciated as I'm currently not sure if this is a problem on our TREP side or if it's with our new IP application.

ema-apiinteractive-provider
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

hi @jonas.karlsson-esklund

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?
If so please can you click the 'Accept' text next to the appropriate reply? This will guide all community members who have a similar question.

Thanks,
AHS

Hi @jonas.karlsson-esklund,

Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.


Thanks,

AHS

Upvotes
Accepted
78.8k 250 52 74

@jonas.karlsson-esklund

This is strange. It looks like the interactive provider application got a close request for the second subscription.

We request the same RIC again, and this is what our IP receives
15:54:39.562 Status Got close request: ReqMsg
streamId="1881"
domain="MarketPrice Domain"
name="EUR/USD"
nameType="1"
serviceId="1"
serviceName="TBID-DEV"
ReqMsgEnd
, handle: 140734437190848

You may need to enable XML tracing in the API to verify the problem. Please refer to the Enterprise Message API (EMA) - Configuration Overview article.

It could be a problem on the TREP side.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes

Thanks for the XML tracing tip, so we've found the issue now.


With the .xml tracing we saw that we actually never received a second close from the TREP but in reality a request.

And we found a "feature" in our code which caused the close to never be removed from a message queue basically, so when the new request arrives, we read the close from the queue again and again.


Thanks for the assistance on this!


//Jonas

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.