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();