[jboss-user] [JBoss Messaging] - Re: BisocketClientInvoker deadlock

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 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); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173063#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...