D
dbeavon
Guest
Is the JMS generic client code (in ABL) available to be reviewed by the public? I have an ABL session in PASOE that is interacting with the "sendToQueue" method on a jms/ptpsession. The ABL session callstack is stuck on "send2" in message-header.p. There has been no change for the past 12 hours. We do a TON of jms and know that the scope of the problem is limited to this single ABL session. Callstack C:\Progress\OpenEdge\jms\impl\message-header.r (send2 jms/impl/message-header.p - 1616) C:\Progress\OpenEdge\jms\impl\session.r (doSend jms/impl/session.p - 2161) C:\Progress\OpenEdge\jms\impl\session.r (sendToQueue jms/impl/session.p - 1950) \\grnetappm03\oe_prod\OpenEdge\USW\LumberTrack\app\p\app0479.r (FetchAsyncDataTransaction app/p/app0479.p - 828) \\grnetappm03\oe_prod\OpenEdge\USW\LumberTrack\app\p\app0479.r (FetchAsyncData app/p/app0479.p - 501) It would be really great if I had some idea what "send2" is doing to make it stuck, so that I can free it up (either manually or introduce a custom workaround that will force a timeout). I've already verified that the PASOE client is not connected, and the HTTP session in tomcat has been expired. But these things weren't enough to free up the ABL session and unlock it from whatever it is doing with the generic jms adapter. Our PASOE environment runs on Windows with version 11.7.4. Any help would be appreciated. This is the first time I've seen anything get locked up at this point in the callstack. We send 100,000's of messages a day. I haven't found any google hits about this so I thought I'd at least start the conversation. The other thing I haven't done yet is to kill the entire PASOE agent, after adding another one in its place. That is going to be the next step, but I'd like to gather information and understand what happened first.
Continue reading...
Continue reading...