M
mbmike29
Guest
Inside the generic JMS adapter in com\progress\jms\messaging\DestCache.java there is a hard coded hash size of 1000 for the various handle cache hash tables you maintain. The OpenEdge generic JMS adapter caches the handle to each new queue they send a message to. The handle is left open until 1000 handles are open at which time all previous open handles are closed. In our use case we have many instances of tomcat (all running many simultaneous threads) sending "request/reply" messages to OpenEdge. While OE is reading from one single queue, every reply is going to a new unique “temporary” queue. Out of the box for IBM MQ version 9, the "MAXHANDLES" parameter is set to 256. This "undocumented" feature of the generic JMS adapter for OE caused us to spend over 250 hours debugging and testing and caused us to delay our critical SonicMQ replacement project by months. We finally reverse engineered (decompiled) your "$DLC/java/progress.jar" file to discover what exactly was happening and that we needed to increase the MAXHANDLES parameter in IBM MQ to work around this "feature". We would also like to note that this value (1000) is hard coded and is not configurable or documented by Progress in any way. Each time our application reaches the 1000 limit there is a detectable delay while the previous 1000 handles are closed. We would like to be able to tune this parameter for our use case. Please change the hard coded limit of 1000 for the maximum size of the topic, queue, temporary topic and temporary queue hash tables to be a configurable value. The code I'm talking about can be found in com\progress\jms\messaging\DestCache.java. This would allow us to tune the size accordingly and not require such a large amount of handles open between any single thread and IBM MQ.
Continue reading...
Continue reading...