2 Replies Latest reply on Jan 23, 2002 12:38 PM by msquance

    How to get memory leak fix into 2.4.x

    msquance

      Hi,

      I've seen postings as well as comments in the source code that indicate that some memory leak problems with publishing/subscribing messages have been resolved.

      My particular problem is that the memory usage continues to grow when I have a client publish a text message repeatedly.

      I have tried 2.4.4 and the problem seems to still exist there.

      I have built the messaging component from HEAD and copied over the jbossmq.jar/jbossmq_client.jar files to my 2.4.4 set-up, but I get errors when I tried to publish from my client:
      javax.naming.NamingException: Invalid reference. Error: org.jboss.mq.GenericConnectionFactory; Local class not compatible: stream classdesc serialVersionUID=-3631035586055025610 local class serialVersionUID=-6897993188562554891

      Is there a particular tag I can use to build from that will work with 2.4.x?

      We need the fix for a system that will be going into production soon and we aren't ready to go to JBoss 3.0 yet.

      Any help would be appreciated.

      Thanks,
      Mike.

        • 1. Re: How to get memory leak fix into 2.4.x
          hchirino

          Is the jbossmq-client.jar on the client side the one that you built off the HEAD branch??

          • 2. Re: How to get memory leak fix into 2.4.x
            msquance

            I can't remember now exactly what I did, but I think I may have been doing something wrong. Regardless, I was able to merge the message cache feature into 2.4.1 and get it working.

            However, I found that it didn't solve the problem (except that the messages were written to disk instead of keeping memory).

            What I was able to discover is that my problem was related to having a topic subscriber listening for messages that fail to match the message selector. It seems that in this case, references to message are never removed.

            I solved it in 2.4.1 (without the message cache merge) by updating BasicQueue.java. Here's the diff (method is internalAddMessage):

            RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java,v
            retrieving revision 1.4.2.1
            diff -r1.4.2.1 BasicQueue.java
            332a333,338
            > } else {
            > //else add to message list
            > synchronized ( messages ) {
            > messages.add( message );
            > }
            334,338d339
            < }
            <
            < //else add to message list
            < synchronized ( messages ) {
            < messages.add( message );

            With the message cache merged, I found that this fix alone did not solve the problem because the reference to the message needed to be removed from the message cache explicitly. I added a hack to BasicQueue that seems to work. Here is the updated code for internalAddMessage:

            private void internalAddMessage(MessageReference message) {
            //try waiting receivers
            synchronized (receivers) {
            if (!receivers.isEmpty()) {
            for (Iterator it = receivers.iterator(); it.hasNext();) {
            Subscription sub = (Subscription) it.next();
            try {
            if (sub.accepts(message.getHeaders())) {
            //queue message for sending to this sub
            queueMessageForSending(sub, message);
            it.remove();
            return;
            } else {
            // ## added this to remove the message reference - leak otherwise
            server.getMessageCache().remove(message);
            }
            } catch (JMSException ignore) {
            cat.debug("Caught unusual exception in internalAddMessage.", ignore);
            }
            }
            } else {
            //else add to message list
            synchronized (messages) {
            messages.add(message);
            }
            }
            }
            }
            }

            Can anyone confirm the bug(s) and/or provide a proper fix?

            Thanks,
            Mike.