Generic JMS Adapter - Lifecycle Question - Forum - OpenEdge Development - Progress Community

Generic JMS Adapter - Lifecycle Question

 Forum

Generic JMS Adapter - Lifecycle Question

This question is not answered

Where is the generic JMS adapter in terms of its lifecycle?  Is it continuing to get any development effort?  In particular I'm thinking of the "brokerconnect" mode of the adapter.

This jms adapter can be very troublesome at times.  And I have a support case related to the adapter that is dragging along quite slowly.  Granted I haven't created the full repro that pinpoints the bug...  but I think that is within reach if someone was motivated to work on that (and had access to simultaneously modify the source code).

Aside from the current bug, I have had several other issues while using the JMS adapter from a PASOE/tomcat host.  (There are concurrency issues and OEE management/licensing issues)...

I believe that support for the "brokerconnect" on PASOE was introduced fairly recently (based on some KB's that I've read).   It might not be the best fit for the PASOE architecture.  But I think Progress is currently committed to supporting this configuration; especially since there are not any great alternatives for messaging. 

My experiences with this adapter on PASOE hasn't been great. It seems that the software development efforts fro this may be stalled at the moment.  It seems likely to me that this adapter thing may become deprecated one day (just like "classic" appserver).  I wonder if there is something new that will replace this adapter?  Or maybe some of the code will be reincarnated within PASOE/tomcat itself, and will support being hosted in a docker container?  (And taking it one step further ...  perhaps a reincarnation of this will NOT require adminserver or the ubroker framework at all)?

I'm wondering if the java code that runs within the adapter could be hosted within a specialized PASOE webapp of some kind?  Maybe something like this would be the long-term direction?

I'd appreciate any information about the future of this adapter.  I'd like to think that Progress will continue to support and enhance the adapter.  But if that is not the case then maybe I can hope that there is an alternative in mind that will arrive shortly.  This adapter needs some TLC; but it feels like it is reaching the end of its road.  The "classic" appserver gave me the same impression before it was finally deprecated in OE 12.

All Replies
  • One thing that might help matters is if Progress would release the source code to the "generic adapter".  (Along with automated test harnesses, if available.).

    That way customers might at least be able to recompile it and troubleshoot it ourselves.  There are a lot of moving parts involved, including the plugin mechanism that allows you to interface with a third-party JMS client library.  Even if the Progress adapter software is running perfectly, it would NOT be easy to differentiate a bug in a third-party JMS client library; so customers still might point the finger at the Progress adapter .

    Open sourcing might be a good option in this case.  I can't imagine there is anything all that proprietary in the "generic adapter".  A bit of ubroker plumbing?  Some TCP/IPC plumbing?  Some JMS interfacing?  Nothing that exciting or interesting.  I doubt any other company is going to create a competing adapter, especially since the Progress one is supposed to be a free part of the adminserver framework (like nameserver).  

    We still get bitten by bugs in the "brokerconnect" version of the adapter running on PASOE/Windows.  Basically an ABL session that is interacting with the adapter will hang from time to time waiting on an exchange with the adapter.  There is no timeout mechanism and the ABL session will block indefinitely while waiting on the connection to the adapter.  Worse yet it will also hold onto any locked records in the database as well, causing massive problems that escalate into other parts of the business application and requires manual intervention in order to recover.  

    I suspect there are some fundamental internal problems with the way that concurrency control is handled in the adapter.  It only affects the "brokerconnect" model which presumably shares resources between "servers".  This stuff never happened in the past when we had relied on "clientconnect" (totally independent processes without inter-session conflicts).  Unfortunately PASOE doesn't support the clientconnect adapter mode at this time.