Author: clebert.suconic(a)jboss.com Date: 2009-11-04 18:29:37 -0500 (Wed, 04 Nov 2009) New Revision: 8214 Modified: trunk/src/main/org/hornetq/core/server/impl/ServerConsumerImpl.java Log: Fixing eventual failure on LargeMessageTest Modified: trunk/src/main/org/hornetq/core/server/impl/ServerConsumerImpl.java =================================================================== --- trunk/src/main/org/hornetq/core/server/impl/ServerConsumerImpl.java 2009-11-04 16:59:56 UTC (rev 8213) +++ trunk/src/main/org/hornetq/core/server/impl/ServerConsumerImpl.java 2009-11-04 23:29:37 UTC (rev 8214) @@ -94,7 +94,7 @@ private volatile LargeMessageDeliverer largeMessageDeliverer = null; - private boolean largeMessageInDelivery; + private volatile boolean largeMessageInDelivery; /** * if we are a browse only consumer we don't need to worry about acknowledgemenets or being started/stopeed by the session. @@ -200,8 +200,6 @@ return HandleStatus.BUSY; } - // note: Since we schedule deliveries to start under replication, we use a counter of pendingLargeMessages. - // If there is a pendingLargeMessage we can't take another message // This has to be checked inside the lock as the set to null is done inside the lock if (largeMessageInDelivery) @@ -625,7 +623,7 @@ private final long sizePendingLargeMessage; /** The current message being processed */ - private LargeServerMessage largeMessage; + private volatile LargeServerMessage largeMessage; private final MessageReference ref; @@ -757,6 +755,13 @@ lock.lock(); try { + if (largeMessage == null) + { + // handleClose could be calling close while handleDeliver is also calling finish. + // As a result one of them could get here after the largeMessage is already gone. + // On that case we just ignore this call + return; + } context.close(); largeMessage.releaseResources();