@emir.subasic
The ping from Eikon to your application that appears to be failing here is the inner working of Eikon .NET API your application is utilizing. You have no control over how this ping is performed. The only variables you can play with are the hardware and operating system resources (make sure your application is not starving of either) and the processing of the updates (make sure your application processes the updates fast enough to keep up with the updates sent by Eikon at all times). Fast updating RICs can receive hundreds of updates per second. If your application cannot process the updates to keep up with the update rate, you may want to consider implementing conflation in your TREP infra to drop some updates and thus slow down the update rate for your application. Or you may want to consider utilizing lower level APIs, which don't provide some of the features of higher level APIs (e.g. CF_ fields), but which will give you more flexibility and better performance.

Hi,

You're using an Eikon API... but which one :

• https://developers.refinitiv.com/eikon-apis/net-apis-use-custom-applications
• https://developers.refinitiv.com/app-studio/app-studio-net-sdk
• https://developers.refinitiv.com/article/net-libraries-eikon-data-apis-quick-start
• https://developers.refinitiv.com/eikon-apis/eikon-data-api
• another one listed here : https://developers.refinitiv.com/eikon-apis/apis-in-this-family ?

If your subcription is on streaming data, something should be logged by Eikon.

You can check pixl log files ( default path : C:\ProgramData\Thomson Reuters\Eikon Data\Logs\TRD\Eikon.<yyyymmdd>.<hhmmss>.<pid>\Realtime )

(to simplify your search, restart eikon with "-nofile" option to avoid loading default workspace)

Hi,

Thanks for looking into this. There are several log files. I can't attach the log files here as the file type is not permitted.

Here is the content from one of them from yesterday:

<@>05/02 13:00:57.973 [ERROR/ECRC.CONFIG] Unable to determine the RFA configuration for secondary connection. Please set the COMMON.PIXL.DEFAULT.RFA.CONFIGURATION.SECONDARY_CONNECTION parameter in your configuration.

<@>05/02 13:00:58.080 [ERROR/ECRT.CORE] pixl::trep::core::detail::ConfigurationAccess<class pixl::trep::core::Configuration>::getNode: Failed to retrieve 'long' value from RFA configuration object. nullptr returned. Path: "\XTRA\Sessions\XtraSession\RecoveryTimerInterval".

<@>05/02 13:00:58.080 [ERROR/ECRT.CORE] pixl::trep::core::detail::ConfigurationAccess<class pixl::trep::core::Configuration>::getNode: Failed to retrieve 'long' value from RFA configuration object. nullptr returned. Path: "\XTRA\Sessions\XtraSession\MaxOpensPerRecoveryIteration".

<@>05/02 13:00:58.080 [ERROR/ECRT.CORE] pixl::trep::core::detail::ConfigurationAccess<class pixl::trep::core::Configuration>::getNode: Failed to create RFA configuration iterator. nullptr returned. Path: "\XTRA\Services".

<@>05/02 13:00:58.080 [ERROR/ECRT.CORE] pixl::trep::core::detail::ConfigurationAccess<class pixl::trep::core::Configuration>::getNode: Failed to retrieve 'string' value from RFA configuration object. nullptr returned. Path: "\Sessions\XtraSession\connectionList".

<@>05/02 13:00:58.559 [ERROR/ECRC.CONFIG] Unable to determine the RFA configuration for secondary connection. Please set the COMMON.PIXL.DEFAULT.RFA.CONFIGURATION.SECONDARY_CONNECTION parameter in your configuration.

<@>05/02 13:00:58.559 [ERROR/ECRS.SHARED_MAIN] LEAVE RFASessionShared::initializeSecondaryConnection = [ERR:Cannot find the second session RFA configuration, path = ]

<@>05/02 13:00:58.559 [ERROR/ECRS.SUB_CONFIG] An error occured while initializing the secondary connection. Error: "Cannot find the second session RFA configuration, path = ".

<@>05/02 13:01:38.611 [ERROR/ECRS.SHARED_MAIN] Session : 077196B8 RFA Context uninitialize failed.

And another one called RtGateway.... from the same time:

<@>02/02 02:21:15.620 [ERROR/ECRC.CONFIG] Unable to determine the RFA configuration for secondary connection. Please set the COMMON.PIXL.DEFAULT.RFA.CONFIGURATION.SECONDARY_CONNECTION parameter in your configuration.

<@>02/02 02:21:15.646 [ERROR/ECRS.SHARED_SERVICES] Unable to read aliases, No aliases defined in configuration.

<@>02/02 02:21:15.946 [ERROR/ECRC.CONFIG] Unable to determine the RFA configuration for secondary connection. Please set the COMMON.PIXL.DEFAULT.RFA.CONFIGURATION.SECONDARY_CONNECTION parameter in your configuration.

<@>02/02 02:21:15.946 [ERROR/ECRS.SHARED_MAIN] LEAVE RFASessionShared::initializeSecondaryConnection = [ERR:Cannot find the second session RFA configuration, path = ]

<@>02/02 02:21:15.947 [ERROR/ECRS.SUB_CONFIG] An error occured while initializing the secondary connection. Error: "Cannot find the second session RFA configuration, path = ".

<@>03/02 13:03:45.290 [ERROR/ECRS.SUB_CALLBACKS] RFA/RSSL_Adapter : [Mon Feb 03 13:03:45 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>03/02 13:03:45.290 ", errno: RSSL_RET_FAILURE [0] - )

<@>03/02 13:03:45.290

<@>03/02 13:03:45.292 [ERROR/ECRP.PUB_CBKS] RFARSSL_Adapter : [Mon Feb 03 13:03:45 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>03/02 13:03:45.292 ", errno: RSSL_RET_FAILURE [0] - )

<@>03/02 13:03:45.292

<@>04/02 12:50:03.451 [ERROR/ECRS.SUB_CALLBACKS] RFA/RSSL_Adapter : [Tue Feb 04 12:50:03 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>04/02 12:50:03.451 ", errno: RSSL_RET_FAILURE [0] - )

<@>04/02 12:50:03.451

<@>04/02 12:50:03.453 [ERROR/ECRP.PUB_CBKS] RFARSSL_Adapter : [Tue Feb 04 12:50:03 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>04/02 12:50:03.453 ", errno: RSSL_RET_FAILURE [0] - )

<@>04/02 12:50:03.453

<@>05/02 13:01:38.627 [ERROR/ECRS.SUB_CALLBACKS] RFA/RSSL_Adapter : [Wed Feb 05 13:01:38 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>05/02 13:01:38.627 ", errno: RSSL_RET_FAILURE [0] - )

<@>05/02 13:01:38.627

<@>05/02 13:01:38.628 [ERROR/ECRP.PUB_CBKS] RFARSSL_Adapter : [Wed Feb 05 13:01:38 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

<@>05/02 13:01:38.628 ", errno: RSSL_RET_FAILURE [0] - )

<@>05/02 13:01:38.628

Any ideas?

Thanks

Message [ERROR/ECRP.PUB_CBKS] RFARSSL_Adapter : [Wed Feb 05 13:01:38 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: RSSL Channel read failed on connection "Connection_EIKON_RTGATEWAY". Channel will be closed. (Internal debug info: "<..\..\..\Ripc\Impl\ripcsrvr.c:6812> Error:1002 ripcRead() failure. Connection reset by peer

=> that means the client (your app or any intermediate layer) closed the subcription.

Let see in UDAP's log files in C:\ProgramData\Thomson Reuters\Eikon Data\Logs\TRD\Eikon.<yyyymmdd>.<hhmmss>.<pid> :

• AppLog.UDASERVICE.yyyymmdd.hhmmss.<pid>
• EikonBox.UDASERVICE.yyyymmdd.hhmmss.<pid>

Hi,

The AppLog.UDASERVICE is too big to upload so I am providing just the last cut down part of the log (see below).

It seems that Eikon sends a PING to my client to which I am not responding and then it unsubscribes all my previously subscribed RICs. I wasn't aware of this logic.

Is this your understanding of the behaviour?

Thanks

[2020-02-06 09:36:32.158|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - New RT Subscription Id:219 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 09:36:32.169|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - New RT Subscription Id:220 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 09:36:32.175|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - New RT Subscription Id:221 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 09:36:38.976|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - New RT Subscription Id:222 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:47.433|16|UDA Service|1|WARNING]ThomsonReuters.Udap.ClientManager - Client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb did not respond to a ping request in a timely fashion, cleaning up.

[2020-02-06 11:26:47.434|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:1 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:47.435|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:2 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:47.437|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:3 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:50.188|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:222 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:50.190|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - Removing listener to PIXL Session for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb - count: 0

[2020-02-06 11:26:50.196|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:1 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:50.199|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:2 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:50.201|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:3 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

....

[2020-02-06 11:26:50.273|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:80 for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb

[2020-02-06 11:26:50.273|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Removing listener to PIXL Session for client FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb - count: 0

[2020-02-06 11:26:50.274|16|UDA Service|2|INFO]ThomsonReuters.Udap.ClientManager - Client (Cookie: FDMEikonAPI_86e261af-44e2-440b-9fe1-3f533321bfeb) has been removed - Total client count : 5

Hi,

Have you had a chance to review my last post please?

Thanks

Hi,

It sin't easy to identify the cause.
Log file will be more meaningful if you switch to DEBUG level.
To do this, start Thomson Reuters Configuration Manager and Thomson Reuters Desktop Trace Level to "4 - Debug (slows down the application)":

In addition, if you find it, you can also start the App "QA: Simple Data Access Tests".
To find it, start App Studio > See more Apps, then search for QA:

Then open it, run and check test results.

HI,

I have had it running in DEBUG mode from yesterday and can see that it has stopped updating this morning.

From the AppLog.UDASERVICE log I can see the following:

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => RT4WebAppsRTService_384ae2cb-610a-4ba4-9d98-c475951ebe0e

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => RT4WebAppsRTService_0cb684c2-6457-4315-89e6-fa437113f98c

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELFLOATING_TOOLBAR_adacc1cf-c2ac-45b1-a40d-16818f664db4

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELTRALERTSENGINE_88b21ee9-4039-419f-98b8-ac86550ac38b

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELEIKONALERTSENGINE_7464e44d-2fe8-4bf5-9cd6-bf49800d7610

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - ClientManager's garbage collection has ended. New schedule in 00:10:00.

[2020-02-12 07:39:59.425|16|UDA Service|1|WARNING]ThomsonReuters.Udap.ClientManager - Client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49 did not respond to a ping request in a timely fashion, cleaning up.

[2020-02-12 07:39:59.427|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.UsageTrackingService - Entering BasicHit("FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49", ClientClosed).

[2020-02-12 07:39:59.427|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.UsageTrackingService - Exiting BasicHit after 0:00:00:00.0000053.

[2020-02-12 07:39:59.427|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Client.Dispose (Cookie=FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49, CountDataProviders=3)

[2020-02-12 07:39:59.429|16|UDA Service|3|DEBUG]ThomsonReuters.Eikon.Ipc.Native.RemotingCore - OnProxyDestroyed called for stub ID ba477711-ccd7-4443-80c6-d2bb3c32a10cRawRealTimeService

[2020-02-12 07:39:59.429|16|UDA Service|3|DEBUG]ThomsonReuters.Eikon.Ipc.Native.ProxyStubBase - DecrementStubUsageCount IRawRealtimeService : 0

[2020-02-12 07:39:59.448|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:1 for client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 07:39:59.449|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.Infra.RicUsageCounter - RICs [/TTFWD] have been unsubscribed.

[2020-02-12 07:39:59.450|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - RT Unsubcribe Id:2 for client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 07:39:59.450|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.Infra.RicUsageCounter - RICs [/CFI3Dc1] have been unsubscribed.

....and so on for all subscribed RICs.

[2020-02-12 07:40:02.048|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlServiceImpl - Removing listener to PIXL Session for client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49 - count: 0

[2020-02-12 07:40:02.049|16|UDA Service|3|DEBUG]ThomsonReuters.Eikon.Ipc.Native.RemotingCore - OnProxyDestroyed called for stub ID e31987a4-8977-4fa9-af51-8a0b6a497072RawChainService

[2020-02-12 07:40:02.049|16|UDA Service|3|DEBUG]ThomsonReuters.Eikon.Ipc.Native.ProxyStubBase - DecrementStubUsageCount IRawChainService : 0

[2020-02-12 07:40:02.061|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:1 for client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 07:40:02.066|16|UDA Service|2|INFO]ThomsonReuters.Udap.PixlChainServiceImpl - Chain Unsubcribed Id:2 for client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

and so on...

It seems that Eikon does send a ping to my application but it seems that earlier on it was getting a response. For example:

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => RT4WebAppsRTService_384ae2cb-610a-4ba4-9d98-c475951ebe0e

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => RT4WebAppsRTService_0cb684c2-6457-4315-89e6-fa437113f98c

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELFLOATING_TOOLBAR_adacc1cf-c2ac-45b1-a40d-16818f664db4

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELTRALERTSENGINE_88b21ee9-4039-419f-98b8-ac86550ac38b

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => ELEIKONALERTSENGINE_7464e44d-2fe8-4bf5-9cd6-bf49800d7610

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 03:14:59.185|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - ClientManager's garbage collection has ended. New schedule in 00:10:00.

[2020-02-12 03:24:59.191|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - ClientManager is starting garbage collection ...

[2020-02-12 03:24:59.191|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - 6 active clients, 0 pending answers.

This leads me to believe that my application was busy receiving messages for subscribed RICs (several thousand RICs) at the time the ping was issued and while it was busy it did not respond to the ping. Is this a plausible scenario? Is there any code that I can add to send a preemptive "I am alive" status to Eikon?

Thanks

Also, the ping seems to timeout in 5 minutes. Is it possible to increase the timeout somewhere?

Thanks

Any updates please?

Thanks

Hi,

The default timeout is 10 seconds, so if you see a time out of 5 seconds, we need to analyze your code.
The scenario you describe is really plausible :
This leads me to believe that my application was busy receiving messages for subscribed RICs (several thousand RICs) at the time the ping was issued and while it was busy it did not respond to the ping

This should leads to high memory and CPU consumption (you can check first with the task manager).

To progress further, we'll need to analyze your code. I suggest you to contact the support and/or your account manager, then send your project without sensible information or a sample that reproduce your issue.

Hi,

The ping timeout appears to be 5 minutes based on the following log:

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - Sending IsAlive => FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49

[2020-02-12 07:34:59.417|16|UDA Service|3|DEBUG]ThomsonReuters.Udap.ClientManager - ClientManager's garbage collection has ended. New schedule in 00:10:00.

[2020-02-12 07:39:59.425|16|UDA Service|1|WARNING]ThomsonReuters.Udap.ClientManager - Client FDMEikonAPI_68a213b6-29b5-430f-ab99-091284412f49 did not respond to a ping request in a timely fashion, cleaning up.

1. Is there any code that I can add to send a preemptive "I am alive" status to Eikon?

2. Is it possible to increase the Eikon timeout somewhere?

The application is embedded in a large solution so it will not be practical to send it. All the code is based on the examples/tutorials and guidance provided on this portal.

Thanks

Emir

Hi,

Have you had a chance to review my last post please?

Thanks

Just following up on this issue. Any updates please?

Thanks

Hi,

Unfortunately, we need much more information to understand the cause.
It should involve the Eikon support and certainly live session to reproduce the issue and debug with you (if you can't extract and send us the impacted code).

Hi @emir.subasic

another approach which often helps in situations like this - try and recreate the issue with smaller snippet of code which you can share.

Hi,

I would assume you can answer the 2 questions without any code samples. i.e:

1. Is there any code that I can add to send a preemptive "I am alive" status to Eikon?

2. Is it possible to increase the Eikon timeout somewhere?

On the code sample.

I subscribe to mainly the 4 chains:

0#TRGBBFVDc

0#TRFRBFVDc

0#TRNLBFVDc

0#TRBEBFVDc:

which expand out to over 5000 RICs. In addition there are a few more RICs added to the subscription so probably around 7000 RICs in total.

The 2 main methods are as follows.

public void CreateAndStartChainSubscription()

{

var realtime = DataServices.Instance.Realtime;

realtime.ServiceInformationChanged += Realtime_ServiceInformationChanged;

chainSubscription = realtime.SetupChainSubscription(symbol.Name)

.OnDataUpdated(ChainUpdatedCallback)

.OnError(ChainErrorCallback)

.CreateAndStart();

log.InfoFormat($"Created and started chain subscription for {symbol.Name}");

}

public void SubscribeAndStartRICs(List<string> rics, List<string> fields)

{

var realtime = DataServices.Instance.Realtime;

Subscription = realtime.SetupDataSubscription()

.WithRics(rics)

.WithFields(fields)

.OnDataUpdated(DataReceivedCallback)

.OnStatusUpdated(StatusUpdatesCallback)

.CreateAndStart();

}

And the callback handling the Data response:

private void DataReceivedCallback(IRealtimeUpdateDictionary updates)

{

foreach (var item in updates)

{

DataTable resultTickTable = GetBaseTickTable();

bool subscribedFieldUpdated = false;

foreach (var ricUpdate in item.Value)

{

AddUpdateToTickTable(ricUpdate.Value, resultTickTable);

if(IsFieldInSubscribedField(ricUpdate.Value.Field))

subscribedFieldUpdated = true;

}

//only save data if we have a field thats in the subscribed list

if (subscribedFieldUpdated)

SaveUpdate(resultTickTable, item.Key);

else

log.InfoFormat($"None of the subscribed fields updated in received data. {item.Key} ignoring updated data {GetAllUpdatedFieldsAsString(resultTickTable)}");

if (log.IsDebugEnabled)

{

log.DebugFormat($"---------RIC {item.Key} Fields Update-----------");

DumpTickTable(resultTickTable);

log.DebugFormat($"---------End RIC {item.Key} Update-----------");

}

}

}

Hi,

Eikon Tech (Angel Gonzales) appears to find no issues with Eikon Connectivity and Eikon does not go down when error occurs.

Are you able to replicate on your side with your code if possible with the sample RICs I provided? This seems to happen only when thousands of RICs are in use.Note: my accounts RIC subscription limit is set to 10000. When I use a couple hundred I do not experience this issue.

Also, Are you able to answer this question please?

1. Is there any code that I can add to send a preemptive "I am alive" status to Eikon Desktop from my application?

Thanks

Hi @emir.subasic

I am not an Eikon / Eikon API expert - but what you are describing reminds me of the 'slow consumer' scenario we sometimes come across when working with our realtime API users.

The workaround we normally suggest to the realtime API developers is to minimise any activity done during the callback event handler- as these are called on the API thread context. This can lead to the API thread being too busy to send the keep alive pings to the server in a timely manner - resulting in the server disconnecting the application. We tell the realtime API developers that If they are doing considerable processing in the event handler / callback, then they should farm that off to additional worker threads and return control back to the API thread as quickly as possible.

So, in your example snippet above, are you able to farm off some of the processing in DataReceivedCallback to another thread perhaps?

Hopefully you will get some advice from the Eikon experts - but I thought I would add my two pennies worth just in case it helps.

Hi,

Thanks for looking into this.

Based on what I am seeing, the DataReceivedCallback is processing responses in milliseconds. For example, between the 2 responses below it takes 26 milliseconds so not sure if I can improve the speed anymore here.

09:02:14.594 [6 ] RICSubscription - Eikon API data imported. TRNLBFVDc287 data

09:02:14.620 [6 ] RICSubscription - Eikon API data imported. TRNLBFVDc300 data

When you say:

This can lead to the API thread being too busy to send the keep alive pings to the server in a timely manner - resulting in the server disconnecting the application.

This is the bit that I don't understand - how does the API send pings? Is there a way for my App to send those pings to the Eikon Desktop? Ideally I would like a line of code in my Application to send a ping every 3 minutes to the Eikon Desktop to tell it that it is alive.

Is this possible and is there a developer thats familiar with this API available to look into this please?

Thanks