[siimk123]

Hi

I have stumbled onto problem as described in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135432 ( BisocketClientInvoker deadlock )

I was stress testing JBoss messaging and under heavy load it occasionally happened that server did not give out connections anymore.
Left it running overnight, but the situation did not improve. It hangs in createSocket infinitely.

Setup:
JBoss 4.2.2GA
JBoss Remoting 2.2.2.SP4-brew
JBoss Messaging 1.4.0 SP3


Then after reading instructions in https://jira.jboss.org/jira/browse/JBMESSAGING-1268, I tried following setup:
JBoss 4.2.2GA
JBoss Remoting 2.2.2.SP7
JBoss Messaging 1.4.0 SP3_CP03 (from svn Branch_JBossMessaging_1_4_0_SP3_CP)

bisocket -> timeout=0
bisocket -> callbackTimeout=10000

From what I gather here, is that proposed workaround is basically to set connection timeout and letting the blocking connection to time out. Thus freeing up resources that would otherwise block also other threads( solution for original deadlock problem ).


Problem is that when subscriber's connection gets lost then messages are also not delivered and they will be not delivered after connection is restored.
Here I must clarify that I use non durable subscribers, but publishers send persistent messages.


Looking at JBoss Messaging source I understood that you dont wait for client side acknowledge when sending to non durable subscription.
Could it be that this is the underlying reason why persistent messages to non durable subscription are left undelivered?

If this is the case, then I believe that there is a bug in JBoss Messaging, because by JMS 1.1 specification you should not give up so easily.

JMS 1.1 spec page 71 paragraph 4.7 Message Delivery Mode states:
A JMS provider must deliver a PERSISTENT message once-and-only-once. This
means a JMS provider failure must not cause it to be lost, and it must not
deliver it twice.



To summarize...
I have persistent messages for non durable subscription and they are not delivered, because of the connection problem.
I believe the correct behaviour should be that those messages will be delivered after reconnect.



Here are some code snippets from Branch_JBossMessaging_1_4_0_SP3_CP to illustrate above allegations.

ServerSessionEndpoint:1873

if (jmsDestination.isTopic())
{
 if (subscriptionName == null)
 {
 // non-durable subscription
 if (log.isTraceEnabled()) { log.trace(this + " creating new non-durable subscription on " + jmsDestination); }

 // Create the non durable sub

 queue = new MessagingQueue(nodeId, GUIDGenerator.generateGUID(),
 idm.getID(), ms, pm, false,
 mDest.getMaxSize(), selector,
 mDest.getFullSize(),
 mDest.getPageSize(),
 mDest.getDownCacheSize(),
 mDest.isClustered(),
 sp.getRecoverDeliveriesTimeout());

ServerConsumerEndpoint:173

if (dest.isTopic() && !messageQueue.isRecoverable())
{
 // This is a consumer of a non durable topic subscription. We don't need to store
 // deliveries since if the consumer is closed or dies the refs go too.
 this.retainDeliveries = false;
}

ServerSessionEndpoint:1316

if (consumer.isRetainDeliveries())
{
 // Add a delivery

 rec = new DeliveryRecord(delivery, consumer, deliveryId);

 deliveries.put(new Long(deliveryId), rec);

 if (trace) { log.trace(this + " added delivery " + deliveryId + ": " + delivery); }
}
else
{
//Acknowledge it now
try
{
 //This basically just releases the memory reference

 if (trace) { log.trace("Acknowledging delivery now"); }

 delivery.acknowledge(null);
}
catch (Throwable t)
{
 log.error("Failed to acknowledge delivery", t);
}
}