TREP API: [CIRCULAR REFERENCE:com.reuters.rfa.common.DeactivatedException]

Hello,

Am currently having [CIRCULARREFERENCE:com.reuters.rfa.common.DeactivatedException] and just wondering if anybody could tell me what is causing and what do I have to do when I encounter this exception.

Regards,

josa

Find more posts tagged with

trep

rfa

elektron

refinitiv-realtime

Accepted answers

zoya faberov

@josa

By successfully consuming the same instruments from StarterConsumer example you have confirmed that your user is permissioned for all the instruments, this is good.

1. StarterConsumer is requesting instruments one by one. The custom one is using Batch View request, to request them in a single request, with a subset of fields. Test your requirement with BatchViewConsumer example from SDK. See if you can confirm Batch View request capability.

2. I can see from the trace that your request is non-streaming. Are you are not keeping dispatch running when your receive your responses?

3. Print "inCleanup" as the first line of your cleanup method and run, or put breakpoint there and debug. You should learn where it's being called from and when.

(From RFA trace I can only tell what happens, not how it's caused by the code)

All comments

josa

Thanks @zoya faberov. Am using RFA 1.0 and below is the details:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.8.0_51-b16 (Oracle Corporation)
Build-Date: 2017-06-28 15:01:20
Specification-Title: RFA Java
Specification-Version: 8.1
Specification-Vendor: Thomson Reuters
package_Version: 8.1.0.L1.all.rrg
Implementation-Version: 8.1.0.L1.all.rrg

Below is the stack trace:

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
INFO: com.reuters.rfa.connection.rssl.nxNamespace.nxConnection
Connection[nxNamespace::nxConnection] = (14:1)

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler sendLoginReqMsg
INFO: com.reuters.rfa.connection.rssl.nxNamespace.nxConnection
Sending Login Request to 10.185.130.129:14002

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler processMsg
INFO: com.reuters.rfa.connection.rssl.nxNamespace.nxConnection
Login received from 10.185.130.129:14002

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.session.omm.OMMInteractiveLoginStatusProvider processOpenStreamForRefresh
WARNING: com.reuters.rfa.session.nxNamespace.nxSession
Connection nxNamespace::nxConnection does not support Pause/Resume. Pause and Resume requests for this connection will be ignored.

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.session.omm.OMMInteractiveLoginStatusProvider processOpenStreamForRefresh
WARNING: com.reuters.rfa.session.nxNamespace.nxSession
Connection nxNamespace::nxConnection does not support optimized Pause/Resume. Optimized Pause/Resume requests will be converted to individual item Pause/Resume requests for this connection.

Apr 12, 2018 12:13:59 PM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler makeDirReq
INFO: com.reuters.rfa.connection.rssl.nxNamespace.nxConnection
Login received from 10.185.130.129:14002

Error connecting to Trep feedcom.numerix.exception.MarketDataFeedException: Error connecting to Trep feed
at com.numerix.market.marketdatatrepapi.impl.TrepDataRequesterImpl.run(TrepDataRequesterImpl.java:276)
at com.numerix.market.marketdatatrepapi.impl.TrepDataRequesterImpl.requestSnapshotData(TrepDataRequesterImpl.java:155)
at com.numerix.market.intraday_market_feed.trepfeed.ReutersTrepMarketAdapter.getIntraDaySnapshotPrices(ReutersTrepMarketAdapter.java:122)
at com.numerix.market.intraday_market_feed.trepfeed.ReutersTrepMarketAdapter.getMarketData(ReutersTrepMarketAdapter.java:151)
at com.numerix.testConnection.TestMe.main(TestMe.java:42)
Suppressed: com.numerix.market.marketdatatrepapi.exceptions.EventDispatcherException: Encounter Exception in EventQueue Dispatcher
... 5 more
Caused by: com.reuters.rfa.common.DeactivatedException
at com.reuters.rfa.internal.common.EventQueueImpl.localDispatch(Unknown Source)
at com.reuters.rfa.internal.common.EventQueueImpl.dispatch(Unknown Source)
at com.numerix.market.marketdatatrepapi.impl.TrepDataRequesterImpl.run(TrepDataRequesterImpl.java:274)
... 4 more
[CIRCULAR REFERENCE:com.reuters.rfa.common.DeactivatedException]

Thanks very much for the assistance.

josa

zoya faberov

Thank you @josa,

You are on the latest RFA Java.

This is the application log, not RFA trace?

Can you enable low level trace log in your application and upload the resultant trace?

This can be done by setting the ipcTraceFlags to 7 in your connection parameters as well as setting mountTrace=true

This should result in a log file with a default name of RFA_RSSL*.log or RFA_SSL*.log depending on your connection type.

For further details on the above and related parameters please refer to the RFAJ_ConfigLoggingGuide.pdf which comes with the RFAJ API package.

If the file is large, please zip before uploading.

Will try to learn more.

---

If you are seeing the above exception on uninitialization/shutdowm, review your unitialization code for consistency, if it is threaded, make sure that unitialization is consistent for all threads.

josa

rfa-rssl.txt

Thanks @zoya faberov. Please find attached the log file.

Regards,

josa

@zoya faberov, the exception is occuring in the code below

public void run() {
long startTime = System.currentTimeMillis();
while ((System.currentTimeMillis() - startTime) < 600000) {
try {
eventQueue.dispatch(1000);
} catch (DispatchException | RuntimeException de) {
throw new EventDispatcherException(de);
}
}
}

How will increasing or decreasing 1000 in the eventQueue dispatch method params affect the code above? Am sure this is what is causing the exception.

Regards,

josa

zoya faberov

@josa,

Having taken a look at the trace, it breaks off right after login close request.

I would check first, if you are not perhaps, dispaching on the queue, after deactivating it? This should lead to the exact exception you are seeing, even if the queue is empty by now.

Another possible approach, has this application started with one of our examples? What was modified/added, likely, at uninitialization stage? That difference could give you the clue you are looking for?

Dispatch loop is what keeps the application running, doing even processing

int dispatch(long waitMillisecs)
      throws DeactivatedException,
             DispatchQueueInGroupExceptionDispatch the next event. Wait for waitMillisecs milliseconds if no event exists.

Therefore, by making this interval too small, you will do a lot of costly unnecessary checking on the dispatch thread, by making it too long, hold up the thread, unnecessarily.

However, if modifying the dispatch timeout appears ot help, you are likely covering up the incorrect uninitialization, rather then fixing it, potentially, the timing issue just becomes less prominent.

---

Would like to mention, that if this is a new app, I would encourage to look at EMA Java to implement. If there is flexibility on your side to use EMA Java to implement your requirements, all these semantics and potential issues will be handled for you by the API, seemlessly, on the background, making the necessary consumer code times smaller, and much simpler. The primary reason EMA, part of the next generation of our APIs, was introduced, so that application developer could spend minimal effort on subscription side, and be able to concentrate on the business side of the requirement.

josa

Hi @zoya faberov, My view reqquester is attached and could you jelp me check if an doing another out of the ordinary?

Regards,

josa

viewdatarequester.txt

zoya faberov

Hi @josa,

I have taken a look at the code you have shared. I do not see anything wrong. I do not see deactivate or unregister called. I know it's in diiferent part of your app.

My line of thought is that if the order of uninitialization, at some point, is not observed, it may result in teh exception you are seeing. Roughly, it is as demonstrated in our consumer examples:

if ( _connIntSpecHandle != null )
        _ommConsumer.unregisterClient(_connIntSpecHandle);


        // unregister all items
        if (_itemManager != null)
            _itemManager.closeRequest();


        // unregister login
        // Allow conditional login unregister.
        // loginCleanup flag is set to false if cleanup is called after login
        // failure.
        if (_loginClient != null && doLoginCleanup)
            _loginClient.closeRequest();


        if (_ommConsumer != null)
            _ommConsumer.destroy();


        _eventQueue.deactivate();
        _session.release();
        Context.uninitialize();

If you are running this from multiple threads, two approaches to find the issue, to me, are:

Put breakpoints before the key steps indicated above->debug->step-by-step try to see if you dispatch after deactivation, or any other unexpected behavior is happening
Put print statements before key points and try to detect "out-of-ordering" this way

If you need more help, and if you/your organization is a TRDC member, open a TRDC ticket, and have our experts look at the complete code.

josa

Thanks @zoya faberov. Please find attached the class that I am doing all the login request and house keeping and let me know if am doing anything wrong.

Regards,

josa

zoya faberov

Hello @josa,

I would put a logging statement as the very first line of cleanup method, and carefully examine the output, to make sure your application only calls it once.

josa

Thanks @zoya faberov. The problem we are having is this. This client application runs as expected with our Reuters test account. But when we use it on a third party client account (different IP and different service name, but same RICs) it returns nothing. Both our test accounr and the clients test account is permissioned for the requested RICS. Any thought what is going on.

NOTE that we can telnet to the clients box.

Regards,

josa

zoya faberov

In the trace, that I find attached, MarketPrice for CLH9 is returned to the consumer:

-> login request
<- login accpet
-> directory request
<- directory IFC, ELEKTRON_DD
-> request MarketPrice CLH9, non-streaming
<- refresh MarketPrice CLH9 ***
-> Close request MarketPrice
-> Close request Login

But it seems that you are saying that nothing is returned?

Does the trace attached before correspond to the run when you get "DeactivatedException"?

--------

Deactivated exception, happens when the application tries to access a deactivated queue. For example, cleanup was run already ( from one request) and then you try to run cleanup again (from another request, usually on a different thread). This is the reasoning for my suggestions above on how to approach debugging.

--------

Yes, it is possible that a consumer will run differently on connecting to a different system. If the timing is different, an issue in the consumer code can be masked on one and exhibit prominently on the other.

--------

If you get nothing with third party account(?) and not the refresh that I see in trace, I would test third party account with a standard client. For example, StarterConsumer that came with RFA Java SDK. Make sure you get a response for the RIC you request. Then move on to the custom consumer testing.

josa

Thanks, @zoya faberov. Will check and get back ASAP.

Regards,

josa

Hi @zoya faberov. Could you please help check this log file?

Regards,

josa

rfa-rssl.txt

zoya faberov

I will take a look.

To clarify what I am reviewing:

Is this trace with "third party account" + Deactivated exception?

Have a you had a chance to test "third party account" + StarterConsumer from SDK?

Thanks

josa

Thanks @zoya faberov. Yes, this is the clients details with the client I have developed. Will try with the starter consumer and get back shortly.

Regards,

josa

zoya faberov

Thanks, this should help

To clarify:

When you run the client you have developer with reuters test account, you get back the data and see no issues?

When you run the client you have developed with third party client account you get no data and get Deactivated exception?

josa

Yes, @zoya faberov

zoya faberov

In your last attached trace:

MarketPrice Batch View request for 6 items:

"CLH9" "HOU8" "IBM.N" "JPY=" "MSFT.OQ" "TRI.N"

view: "BID" and "ASK"

I see refresh responses for CLH9 and HOU8, and no refresh responses for the rest. The there is close requests for all 6 MP streams and login close.

Are you seeing and paring these refresh responses?

Does Deactivation exception happen after that?

Please confirm the client account you use to consume is permissioned for the rest of the instruments and should be receiving them, do you register for and parse "not entitled" status?

josa

Thanks @zoya faberov. The starter consumer works. It has to be a problem with my client code. Will run in debug and get back. Could it be because am downloading dictionary on application?

Regards,

josa

@zoya faberov, the attached is what am getting from my application. Could you help check why am my application is closing the connection too soon?

Regards,

josa

rfa-rssl.txt

zoya faberov

Hi @josa

Which instrument have you tested with StarterConsumer?

Please try all the same ones you subscribe with your test batch.

josa

@zoya faberov, I tested with same instruments.

zoya faberov

@josa

By successfully consuming the same instruments from StarterConsumer example you have confirmed that your user is permissioned for all the instruments, this is good.

2. I can see from the trace that your request is non-streaming. Are you are not keeping dispatch running when your receive your responses?

3. Print "inCleanup" as the first line of your cleanup method and run, or put breakpoint there and debug. You should learn where it's being called from and when.

(From RFA trace I can only tell what happens, not how it's caused by the code)

josa

Thanks @zoya faberov. Checking and will get back ASAP.

Nipat Kunvutipongsak

Any feedback after checking the result?

josa

Thanks @zoya faberov. Please close this ticket.

EXPLORE OUR SITES