Sorry, my bad.

I've rolled back the changes to the position of node.incrementReferenceCount, but I did maintain the change for incrementPreloadSize, since this was causing the memory leak in the subscription.

Hope this is ok.

[EMAIL PROTECTED] wrote:

Hello,

By adding an incrementReferenceCount and decrementReferenceCount to the
PrefetchSubscription::dispatch method I have fixed the null message
problem I was experiencing.

   private void dispatch(final MessageReference node) throws
IOException {
       try {
node.incrementReferenceCount(); final Message message = node.getMessage();
           if( message == null ) {
               return;
} // Make sure we can dispatch a message.
           if( canDispatch(node) ) {
MessageDispatch md = createMessageDispatch(node,
message);
               dispatched.addLast(node);
node.incrementReferenceCount(); incrementPreloadSize(node.getMessage().getSize()); if( info.isDispatchAsync() ) {
                   md.setConsumer(new Runnable(){
                       public void run() {
                           onDispatch(node, message);
                       }
                   });
                   context.getConnection().dispatchAsync(md);
               } else {
                   context.getConnection().dispatchSync(md);
                   onDispatch(node, message);
               }
           }
       }
       finally {
          node.decrementReferenceCount();
       }
   }

Regards,

Marcus
-----Original Message-----
From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: 23 December 2005 07:37 PM
To: [email protected]
Cc: [email protected]
Subject: Re: svn commit: r358785 -
/incubator/activemq/trunk/activemq-core/src/main/java/org/activemq/broke
r/region/PrefetchSubscription.java

Hi Adrian,

doing a getMessage() before incrementReferenceCount() is dangerous since
the message could have been swapped out and the call to
getMessage() will return null.
Yes, I know there is a null check to see if the message is null, but
that should only happen if the message was expired.  Right now I think
it's possible that we are going to have cases of where messages get
swapped out and this code is going to think that the message has been
expired.

Regards,
Hiram


On Dec 23, 2005, at 4:48 AM, [EMAIL PROTECTED] wrote:

Author: aco
Date: Fri Dec 23 01:47:47 2005
New Revision: 358785

URL: http://svn.apache.org/viewcvs?rev=358785&view=rev
Log:
Postpone incrementing of reference count and preload size, only after we are sure that the message will be dispatched by the current subscription. This is to prevent a memory leak type of scenario.

Modified:
   incubator/activemq/trunk/activemq-core/src/main/java/org/
activemq/broker/region/PrefetchSubscription.java

Modified: incubator/activemq/trunk/activemq-core/src/main/java/org/
activemq/broker/region/PrefetchSubscription.java
URL: http://svn.apache.org/viewcvs/incubator/activemq/trunk/
activemq-core/src/main/java/org/activemq/broker/region/
PrefetchSubscription.java?rev=358785&r1=358784&r2=358785&view=diff
======================================================================
========
--- incubator/activemq/trunk/activemq-core/src/main/java/org/
activemq/broker/region/PrefetchSubscription.java (original)
+++ incubator/activemq/trunk/activemq-core/src/main/java/org/
activemq/broker/region/PrefetchSubscription.java Fri Dec 23
01:47:47 2005
@@ -239,19 +239,19 @@

private void dispatch(final MessageReference node) throws IOException {

-        node.incrementReferenceCount();
-
        final Message message = node.getMessage();
        if( message == null ) {
            return;
-        }
-        incrementPreloadSize(node.getMessage().getSize());
+        }

        // Make sure we can dispatch a message.
        if( canDispatch(node) ) {

MessageDispatch md = createMessageDispatch(node, message);
            dispatched.addLast(node);
+
+            node.incrementReferenceCount();
+            incrementPreloadSize(node.getMessage().getSize());

            if( info.isDispatchAsync() ) {
                md.setConsumer(new Runnable(){



___________________________________________________________

Important Notice: Authorised Financial Services Provider

Important restrictions, qualifications and disclaimers ("the Disclaimer") apply to this email. To read this click on the following address or copy into your Internet browser:
http://www.absa.co.za/disclaimer

The Disclaimer forms part of the content of this email in terms of section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you are unable to access the Disclaimer, send a blank e-mail to [EMAIL PROTECTED] and we will send you a copy of the Disclaimer.


Reply via email to