EMA Java API dead lock

ahmire.kailer

EMA Java API version: 3.4.0.1

I don't know how it happened. I use API dispatch. I remember seeing a suggestion about dead lock problem somewhere that using user dispatch would solve the problem, is there another/better workaround?

"pool-14-thread-1" - Thread t@51
   java.lang.Thread.State: WAITING
        at sun.misc.Unsafe.park(Native Method)
        - waiting to lock <19fb84cb> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) owned by "pool-16-thread-1" t@53
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.submitChannel(Reactor.java:1985)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.encodeIntoBufferAndWrite(WlStream.java:748)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.sendCloseMsg(WlStream.java:793)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.timeout(WlStream.java:305)
        at com.thomsonreuters.upa.valueadd.reactor.Watchlist.timeout(Watchlist.java:328)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.processWorkerEvent(Reactor.java:2677)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.dispatchChannel(Reactor.java:1968)
        at com.thomsonreuters.upa.valueadd.reactor.ReactorChannel.dispatch(ReactorChannel.java:559)
        at com.thomsonreuters.ema.access.OmmBaseImpl.rsslReactorDispatchLoop(OmmBaseImpl.java:1289)
        at com.thomsonreuters.ema.access.OmmBaseImpl.run(OmmBaseImpl.java:1422)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - locked <10ad20cb> (a java.util.concurrent.ThreadPoolExecutor$Worker)

        - locked <3f6430cf> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

        - locked <75b3318c> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

"pool-16-thread-1" - Thread t@53
   java.lang.Thread.State: WAITING
        at sun.misc.Unsafe.park(Native Method)
        - waiting to lock <75b3318c> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) owned by "pool-14-thread-1" t@51
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.submitChannel(Reactor.java:1985)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.encodeIntoBufferAndWrite(WlStream.java:748)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.sendCloseMsg(WlStream.java:793)
        at com.thomsonreuters.upa.valueadd.reactor.WlStream.timeout(WlStream.java:305)
        at com.thomsonreuters.upa.valueadd.reactor.Watchlist.timeout(Watchlist.java:328)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.processWorkerEvent(Reactor.java:2677)
        at com.thomsonreuters.upa.valueadd.reactor.Reactor.dispatchChannel(Reactor.java:1968)
        at com.thomsonreuters.upa.valueadd.reactor.ReactorChannel.dispatch(ReactorChannel.java:559)
        at com.thomsonreuters.ema.access.OmmBaseImpl.rsslReactorDispatchLoop(OmmBaseImpl.java:1289)
        at com.thomsonreuters.ema.access.OmmBaseImpl.run(OmmBaseImpl.java:1422)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - locked <19fb84cb> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

        - locked <37e30fd5> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

        - locked <3e792ce3> (a java.util.concurrent.ThreadPoolExecutor$Worker)

pimchaya.wongrukun01

Hello @-

I suggest you try to use the latest EMA 3.5.0.0 shipped with Elektron SDK Java version 1.5.0.L1

If the problem still occurs with EMA 3.5.0.0, you can submit the problem to the Elektron SDK development team directly via Refinitiv/Elektron-SDK Github . The team should be able to provide you another workaround or fix the problem.

zoya faberov

Hello @-,

Did you have a chance to try the approach suggested by @Pimchaya.Wongrukun?

It would be really helpful for the community, if you could share your findings with us?

Thanks,

-AHS

a0z

Hi @zoya.farberov

This is my new account after the site login change. I tried ema-3.5.0.1.jar recently, and there's still a threading problem. To summarize what I found:

• ema-3.4.0.1.jar with API dispatch - deadlock
• ema-3.5.0.1.jar with user dispatch - deadlock
• ema-3.4.0.1.jar with user dispatch - no deadlock

ema-3.5.0.1.jar threading problem was first raised in https://community.developers.refinitiv.com/questions/63662/ema-java-user-dispatcher-thread-deadlock.html

zoya faberov

Hello @sumedh.suede,

Please raise this issue directly with Elektron SDK development team via Real-Time-SDK (Elektron SDK) on Github

Issues -> create a new issue, with the full description of what you observe and how to reproduce it.

This is done so that Elektron SDK development team can directly review, investigate and potentially track the progress.