question

Upvotes
Accepted
1 0 0 2

Thread lock on MessageQueue.dequeue call in rfa.jar

rfa.jar is used in a batch job that snaps the quotes mid-day and saves to db.

Time to time, a call to EventSourceImpl.destroy() gets stuck forcing us to kill and restart the batch job. Below is the call stack. Has anyone seen this before?

"XXEngine" daemon prio=6 tid=0x0000000034a1d800 nid=0x5bb4 in Object.wait() [0x0000000041c2f000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on <0x0000000bbcbac368> (a com.reuters.rfa.internal.common.MessageQueue)

at java.lang.Object.wait(Object.java:485)

at com.reuters.rfa.internal.common.MessageQueue.dequeue(MessageQueue.java:56)

- locked <0x0000000bbcbac368> (a com.reuters.rfa.internal.common.MessageQueue)

at com.reuters.rfa.internal.common.EventQueueImpl.localDispatch(EventQueueImpl.java:206)

at com.reuters.rfa.internal.common.EventQueueImpl.dispatch(EventQueueImpl.java:170)

at com.reuters.rfa.internal.common.SyncClient.dispatchUntilResponse(SyncClient.java:20)

at com.reuters.rfa.internal.session.EventSourceImpl.destroy(EventSourceImpl.java:146)

Following is the jar version info in manifest file.

Manifest-Version: 1.0

Package-Version: 7.2.0.L1.all

Implementation-Version: 7.2.0.L1.all

Specification-Vendor: ThomsonReuters

Specification-Title: RFA Java

Created-By: 1.6.0_25 (Sun Microsystems Inc.)

Specification-Version: 7.2

treprfarfa-apimulti-threadingmessage-queue
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
Accepted
32.2k 40 11 19

Hello @bryoncho,

It appears that you are using an obsoleted version of RFA Java.

RFA is currently supported in version 7.6+,

Please refer to API Obsolescence Doc to confirm the support of an API version.

Many fixes were implemented since 7.2, and especially in version 8, the major release, that you are not able to benefit from.

Are you on OMM/RSSL? If that is the case, I would plan upgrading to RFA Java 8.

If you are on MarketData/SSL, moving ot OMM/RSSL would be a bit of are-code, so to get the most benefit out of the migration, I would consider to plan a migration to EMA, in Elektron SDK Java area one will find Quickstart guide, multiple Tutorials, Guides and many different examples, to get one started in EMA coding quickly and efficiently.

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
1 0 0 2

Vendor product that uses rfa.jar is on Java 1.6 so maybe that means until we upgrade to newer vendor version (which is on Java 8), there is no way to address the issue - it sounds like this is the case? I am not sure if vendor product is using MarketData/SSL or OMM/RSSL - I could look into this.

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
32.2k 40 11 19

Hello @bryoncho,

Yes. 1.6 is not supported anymore, please refer to API Compatibility Matrix.

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
1.5k 4 5 7

Apart from the old version of the RFA and the old version of Java, there's nothing indicating anything incorrect in the thread dump you've provided. It would be normal for an RFA application to "wait" on the RFA Message Queue until something arrives.


To be honest, I think it is more likely the application is just incorrectly made. A well-behaved application shouldn't wait indefinitely on anything, RFA or no RFA. Instead it should use timeout. This being said it may theoretically be an RFA issue, in which case an upgrade will help.

You can pretty easily derive from the application's config if it use the MarketData/SSL interface (long time deprecated) or the OMM/RSSL interface.

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.