lock on request

Unknown

Hi,

I'm using new api from SFC - Java Edition - 3.5.6.L1.RRG.

During a realtime subscribtion it seems that a deadlock is created, below you can find stack trace:

"BkJmsRpl_0":
at com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue.makeRequest(SSLRecordRequestQueue.java:149)
- waiting to lock <0x00000000f112a3b0> (a com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue)
at com.reuters.sfc.ssl.realtime.SSLProxyRTRecordService.processHasRecordView(SSLProxyRTRecordService.java:311)
at com.reuters.sfc.realtime.RTRecordImplEx.addRecordView(RTRecordImplEx.java:250)
at com.reuters.sfc.realtime.RTRecordServiceImplEx.recordViewInit(RTRecordServiceImplEx.java:518)
at com.reuters.sfc.realtime.RTRecordServiceImplEx.recordViewInit(RTRecordServiceImplEx.java:493)
at com.reuters.sfc.realtime.RTRecordServiceImplEx.rtRecord(RTRecordServiceImplEx.java:470)
- locked <0x00000000f18b4c70> (a com.reuters.sfc.ssl.realtime.SSLRTRecordService)
at it.iwbank.reuter.REUConnection.subscribe(REUConnection.java:83)
at it.iwbank.reuter.REUSubscriber.subscribe(REUSubscriber.java:67)
at it.iwbank.reuter.REUSubscriberLink.subscribe(REUSubscriberLink.java:42)
at it.iwbank.mdf.reuter.REUSession.subscribe(REUSession.java:364)
- locked <0x00000000f136c738> (a it.iwbank.mdf.reuter.REUSession)
at it.iwbank.mdf.reuter.REUSession.subscribe(REUSession.java:311)
- locked <0x00000000f136c738> (a it.iwbank.mdf.reuter.REUSession)
at it.iwbank.mdf.MarketConnection.subscribe(MarketConnection.java:598)
at it.iwbank.mff.mkt.connection.MktConnection.subscribe(MktConnection.java:305)
at it.iwbank.mff.mkt.subscriber.MKTSubscriber.Subscribe(MKTSubscriber.java:232)
at it.iwbank.mff.mkt.subscriber.MKTSubscriber.recovery(MKTSubscriber.java:396)
at it.iwbank.mff.mkt.subscriber.MKTSubscriber.Recovery(MKTSubscriber.java:311)
at it.iwbank.mff.mkt.request.AbRequestReceive.RUN(AbRequestReceive.java:109)
at it.iwbank.mff.util.ThreadControl$1.run(ThreadControl.java:18)
"JSFC Event Thread 0":
at com.reuters.sfc.realtime.RTRecordServiceImplEx.rtRecordImplEx(RTRecordServiceImplEx.java:262)
- waiting to lock <0x00000000f18b4c70> (a com.reuters.sfc.ssl.realtime.SSLRTRecordService)
at com.reuters.sfc.ssl.realtime.SSLProxyRTRecordService.sendRequest(SSLProxyRTRecordService.java:220)
at com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue.flushRequests(SSLRecordRequestQueue.java:136)
- locked <0x00000000f112a3b0> (a com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue)
at com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue.completeViewRequest(SSLRecordRequestQueue.java:123)
- locked <0x00000000f112a3b0> (a com.reuters.sfc.ssl.realtime.SSLRecordRequestQueue)
at com.reuters.sfc.ssl.realtime.SSLProxyRTRecordService.completeViewRequest(SSLProxyRTRecordService.java:212)
- locked <0x00000000f18a4790> (a com.reuters.sfc.ssl.realtime.SSLProxyRTRecordService)
at com.reuters.sfc.ssl.realtime.SSLRecordMessageParser.processItemImage(SSLRecordMessageParser.java:114)
at com.reuters.sfc.ssl.realtime.SSLRecordMessageParser.processMessage(SSLRecordMessageParser.java:36)
at com.reuters.sfc.ssl.realtime.SSLProxyRTRecordService.processConnectionMessage(SSLProxyRTRecordService.java:231)
at com.reuters.sfc.ssl.SapiClientConnection.processDataReceived(SapiClientConnection.java:556)
at com.reuters.ssl.api.java.JavaSapiSubscriber.dispatchPT1BEMessage(JavaSapiSubscriber.java:795)
at com.reuters.ssl.api.java.JavaSapiSubscriber.parseMessage(JavaSapiSubscriber.java:761)
at com.reuters.ssl.api.java.JavaSapiSubscriber.processTransportData(JavaSapiSubscriber.java:696)
at com.reuters.sfc.ssl.TransportClientCmdQueue$TransportDataCmd.run(TransportClientCmdQueue.java:30)
at com.reuters.sfc.EventQueue.run(EventQueue.java:271)
at java.lang.Thread.run(Thread.java:745)

Can you help me to solve the problem?

Thanks

Nipat Kunvutipongsak

Hello @carlo.ernesto.rossi , it seems like this is one of the known issues of JSFC 3.5.6.L1.

This issue happens when the application requests a lot of items, and also specify fields in the request (called 'View Record'. otherwise, it will be 'Full Record' when fields are not specified in the request). Does the application behave like this?

Could you try upgrading the JSFC library to 3.5.6.E1? The problem should not happen again with this patch.