4 Replies Latest reply on Mar 19, 2003 4:28 PM by Adrian Brock

    New JBossMQ IL : OIL2

    Hiram Chirino Expert

      Hi guys,

      Just wanted to let you guys know about a new Invocation Layer for JBossMQ.
      It's called OIL2 because it's closest relative is the current OIL Invocation

      I'm very exited about this new IL because it has some very nice performance
      features. It has low serialization over-head like the old OIL used to have,
      but it only uses one socket like the UIL. Furthermore, when multiple client
      threads share the connection, the connection will be multiplexed between the

      The OIL and UIL ILs used to suffer severely when multiple client threads
      shared the connection. I've added a new test to the test suite which can be
      used to view the performance of the different ILs when multiple threads are
      sharing a single connection. The results for test case which uses 20
      threads sending and receiving 200 messages are:

      As you can see the OIL2 IL did nicely. Hopefully we can make this the default IL soon. If you want to test it out, get a new CVS snapshot, and do a jndi lookup of "OIL2ConnectionFactory" for your connection factory.


        • 1. Re: New JBossMQ IL : OIL2
          john Newbie

          I've been working with oil2 for a while now and I've done some performance monitoring with it. I found a problem with HashMap$Entry instances. First I'm using Jbos 3.0.5. I have a client that kept running out of memory and as I lost memory the number of send and receives I could do began to decrease. I ran with Optimizit and discovered million of HashMap$Entry instances being created even with a small number of sends (3-5 hundred). The two places where this was happening was in Oil2SocketHandler, specifically in the two methods registerResponseSlot and pumpMessages. The same code is in both methods:

          HashMap newMap = (HashMap) responseSlots.clone();
          slot = (Slot) newMap.remov(response.correlationRequestId);
          responseSlots = newMap;

          What is happening here is an exponential increase in HashMap$Entry instances. This was very easy to identify. All you would have to do is create a client that used oil2 and send a constant stream of messages. Eventually you would eat up all of your memory.

          I was able to fix this by replacing the above code to

          slot = (Slot)responseSlots.removresponse.correlationRequestId);

          And I had to put a synchronized block around snapShot iterator code in the pumpMessage methods finally block like this:

          synchronized (responseSlotsMutex)
          HashMap snapShot = responseSlots;
          if (snapShot.size() > 0)
          Iterator i = snapShot.values().iterator();
          while (i.hasNext())
          Slot s = (Slot) i.next();
          if (s != mySlot)
          s.offer(this, 0);

          I'm hoping this can be added to the source code. It completely fix the memory problem and the degredation in send and receives over time went away.

          • 2. Re: New JBossMQ IL : OIL2
            john Newbie

            Sorry the version of JBoss I'm using is 3.0.6 and the replaced code was missing a parenthesis and should read

            slot = (Slot) responseSlots.remove(response.correlationRequestId);

            • 3. Re: New JBossMQ IL : OIL2
              Ivens Porto Newbie

              I've being testing OIL2 and UIL2 invocation layers in JBoss 3.2RC3 and they are very good, very fast. On my computer version 3.2RC3 is at least 3 times faster than version 3.0.x.

              But in my tests I see that one problem still persist, JBossMQ does not scale well. Message throughput drops almost linearly with the number of producers/consumers.

              So I would like to ask, is there any work being done to make JBossMQ scale better? If so, will it be released in the 3.2 series or 4.0 series?


              • 4. Re: New JBossMQ IL : OIL2
                Adrian Brock Master

                Do you have any profiling data?
                I've removed some of the brain deaths,
                but I haven't really profiled a real jms application.

                I noticed the other day that the file persistence
                manager gets stuck synchronizing when creating
                a new transaction.

                There are plans for a major overhaul in the 4.0