Thanks for the note on this. It looks like my problem may have been specific
to the JMS component, however. I downloaded the fuse release (3.3.1.3-fuse)
and was not able to reproduce the hang. I applied a few selective patches
based on the diffs for that release and it looks like the following ticket
fixed our hang issue: http://open.iona.com/issues/browse/ESB-95

What's interesting is that in the trunk AbstractConsumerEndpoint the
'onMessage' function does not seem to have the exception handling fix that's
in the IONA release. Here is the specific portion of the patch from
3.3.1.3-fuse to 3.2.1 for reference:

---
deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/endpoints/AbstractConsumerEndpoint.java
(revision 3799)
+++
deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/endpoints/AbstractConsumerEndpoint.java
(working copy)
@@ -413,9 +418,13 @@
         if (logger.isTraceEnabled()) {
             logger.trace("Received: " + jmsMessage);
         }
+        
+        JmsContext context = null;
+        MessageExchange exchange = null;
+        
         try {
-            JmsContext context = marshaler.createContext(jmsMessage);
-            MessageExchange exchange = marshaler.createExchange(context,
getContext());
+            context = marshaler.createContext(jmsMessage);
+            exchange = marshaler.createExchange(context, getContext());
             configureExchangeTarget(exchange);
             if (synchronous) {
                 try {
@@ -444,10 +453,12 @@
                     }
                 }
             }
-        } catch (JMSException e) {
-            throw e;
         } catch (Exception e) {
-            throw (JMSException) new JMSException("Error sending JBI
exchange").initCause(e);
+            try {
+                handleException(exchange, e, session, context);
+            } catch (Exception e1) {
+                throw (JMSException) new JMSException("Error sending JBI
exchange").initCause(e);
+            }
         }
     }

Let me know if it makes sense to apply this to the trunk as well, and I can
create a ticket for this issue.

Thanks,
Brian


gnodet wrote:
> 
> Well, i'm currently working on a related issue.  The first thing is to
> change the order in which services are shutdown in
> JBIContainer#shutDown.
> Especially, the broker / registry order is wrong (even if there is  a
> comment saying otherwise).  The reason is that the jms listener is
> waiting for all threads to be finished before actually shutting down
> and this can't really happen if the registry is shutdown before,
> because all exchanges won't be processed correctly.
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> 
> 

-- 
View this message in context: 
http://www.nabble.com/sendSync-deadlock-on-downed-endpoint-tp18363507p18392054.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Reply via email to