[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: JMS generic client stuck since yesterday.

[dbeavon]

I'm still working with tech support on this "JMS generic adapter" issue. The current theory is that the root problem might be as simple as a TCP transport issue ... whereby the interaction with the remote broker becomes unresponsive and there is no timeout in effect so ABL is forced to hang indefinitely. (It isn't too surprising that we are scrutinizing the remote broker connectivity - rather that the various moving-parts on the local server where Progress is running). I agree that a javastack trace from the adapter would be helpful if I could get one. So far I haven't been able to recreate the problem on demand. This whole "JMS generic adapter" thing is kind of crazy stuff. My own ABL code runs in a process that is *two* levels of indirection away from the messaging broker. And actual client connection is happening in a third-party jar that Progress doesn't necessarily support. In the Java runtime. And the jar, in turn, speaks to a messaging broker with a proprietary wire protocol. If/when issues arise with this configuration, the majority of issues are things that Progress can blame on a third-party. To be fair ... Progress does own the "JMS generic adapter" and supports that. But that generic adapter doesn't currently seem to have error detection logic that would interrupt a client that is misbehaving. EG. If an ABL program is trying to send a message and the "generic adapter" is blocked for a long period of time - EVEN if it is waiting on a third-party JMS implementation - then there should be a way for it to *abandon* the operation and return control to ABL again with a failure message. It seems like the "JMS generic adapter" is just as much at fault for blocking execution. It is not just the fault of the remote messaging broker. I wish Progress would provide native AMQP support to talk directly to a messaging broker from ABL code. The complexity would be reduced, and we'd eliminate extra hops, additional processes, and the need for the Java runtime. By now there are probably *lots* of open source implementations of AMQP that Progress could copy from.

Continue reading...