2 Replies Latest reply on Sep 27, 2013 7:17 AM by Paul Manning

    Does anyone know if HornetQ 2.2.8 or greater works with JBossAS5 and JBossESB4.10

    Paul Manning Newbie

      All,

       

      Our current configuration is JBoss AS 5.1, JBoss ESB 4.10 and HornetQ 2.2.5. We are currently seeing an issue that appears to be related to a bug in HornetQ (https://issues.jboss.org/browse/HORNETQ-722).

      This bug was fixed in version 2.2.8 of HornetQ. One issue is that I cannot download a distro of 2.2.8, it looks like I would have to build it from source. Second issue, I downloaded the latest 2.2.14 distro of HornetQ and that does not seem to work with AS 5.1. Just curious if anyone knows if this version of HornetQ will work or if anyone has a version > 2.2.5 working in this environment. Thanks,

       

      Paul Manning

        • 1. Re: Does anyone know if HornetQ 2.2.8 or greater works with JBossAS5 and JBossESB4.10
          Tom Cunningham Master

          Hi Paul,

           

          You might want to ask on the hornetq forums :

          https://community.jboss.org/en/hornetq

           

          The 2.2.X releases might be the last ones that work against AS 5.1.0.GA, but the people on the hornetq forum would know.

          • 2. Re: Does anyone know if HornetQ 2.2.8 or greater works with JBossAS5 and JBossESB4.10
            Paul Manning Newbie

            Thanks Tom.

             

            For others that may read this post, we figured out our problem. I applied the fix from v2.2.8 to v2.2.5 source and rebuilt. It turns out that was not our issue. After some profiling, it turns out that we were getting bitten by using Redelivery-Delay. We had setup throughput tests that slammed tons of messages into our system. Several queues had the delay set to a non-zero value. Since we are using Camel JMS with Spring's DefaultMessageListenerContainer under the covers, message consumers were being open/closed repeatedly, internally closing the concrete HornetQ consumer and flushing its internal message buffer. Each message was then getting marked for re-delivery, setting the scheduled delivery time on each message in the buffer. In cases where we had slow consumers, this forced messages to get backed up many times until finally the last group of messages through the system were all spaced out by a factor of the Redelivery-Delay. The other side effect of course was that all of our messages were out of order, in a system where the order of messages is a high priority. We fixed the issue by turning off redelivery-delay and setting the ConsumerWindowSize to 0. I think that we could also address the issue by caching Message consumers, but that will be a much bigger change at the moment.