You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Hadrian Zbarcea (JIRA)" <ji...@apache.org> on 2010/07/13 18:00:51 UTC
[jira] Created: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
JMS Flow only uses one connection even with a PooledConnectionFactory
---------------------------------------------------------------------
Key: SM-1964
URL: https://issues.apache.org/activemq/browse/SM-1964
Project: ServiceMix
Issue Type: Improvement
Affects Versions: 3.3.2
Reporter: Hadrian Zbarcea
Fix For: 3.3.3
The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
If the flow is defined such that:
* during the flow messages are produced and send back to a queue and
* a failover transport is used (which uses a MutexTransport internally) and
* the broker where we enqueue is slow
then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Jamie Goodyear (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jamie Goodyear resolved SM-1964.
--------------------------------
Resolution: Fixed
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Chris Custine (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60649#action_60649 ]
Chris Custine commented on SM-1964:
-----------------------------------
Patch applied, with thanks to Hadrian Zbarcea.
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Jamie Goodyear (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60829#action_60829 ]
Jamie Goodyear commented on SM-1964:
------------------------------------
Patch applied, with thanks to Hadrian Zbarcea.
Sending core/servicemix-core/src/main/java/org/apache/servicemix/jbi/nmr/flow/jms/AbstractJMSFlow.java
Transmitting file data .
Committed revision 966303.
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea updated SM-1964:
--------------------------------
Attachment: sm-1964-2.patch
Adding missing check.
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Suresh Avadhanula (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Avadhanula updated SM-1964:
----------------------------------
Attachment: PooledConnectionFix.patch
Fix bugs in AbstractJMSFlow support for PooledConnection
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: PooledConnectionFix.patch, sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Chris Custine (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Custine resolved SM-1964.
-------------------------------
Resolution: Fixed
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Suresh Avadhanula (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61679#action_61679 ]
Suresh Avadhanula commented on SM-1964:
---------------------------------------
The patch introduced bugs whereby the connection is closed the first time it is used and henceforth throws the following exception
javax.jbi.messaging.MessagingException: org.apache.activemq.AlreadyClosedException: this connection
at org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow.doRouting(AbstractJMSFlow.java:504)
at org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow.doSend(AbstractJMSFlow.java:432)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(AbstractFlow.java:124)
at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(DefaultBroker.java:283)
at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(JBIContainer.java:903)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:405)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:441)
at org.apache.servicemix.components.util.PojoSupport.done(PojoSupport.java:200)
at com.dorado.servicemix.client.DOSMXClient.onMessageExchange(DOSMXClient.java:288)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:632)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:185)
at org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow.access$401(AbstractJMSFlow.java:64)
at org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow$4.run(AbstractJMSFlow.java:533)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.activemq.AlreadyClosedException: this connection
at org.apache.activemq.pool.PooledConnection.assertNotClosed(PooledConnection.java:161)
at org.apache.activemq.pool.PooledConnection.start(PooledConnection.java:77)
at org.apache.servicemix.jbi.nmr.flow.jms.AbstractJMSFlow.doRouting(AbstractJMSFlow.java:480)
I attached the fix in the patch
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: PooledConnectionFix.patch, sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Suresh Avadhanula (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Avadhanula reopened SM-1964:
-----------------------------------
The code breaks when using servicemix with pooled connection
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: PooledConnectionFix.patch, sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea reopened SM-1964:
---------------------------------
First patch was incomplete, see second one. If the pool only has one connection it's used for the broadcast, so that one should be used.
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: sm-1964-2.patch, smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Chris Custine (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Custine reassigned SM-1964:
---------------------------------
Assignee: Chris Custine
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Assignee: Chris Custine
> Fix For: 3.3.3
>
> Attachments: smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60633#action_60633 ]
Hadrian Zbarcea commented on SM-1964:
-------------------------------------
Patch attached, I'll try to put together a unit test as well.
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Fix For: 3.3.3
>
> Attachments: smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1964) JMS Flow only uses one connection even
with a PooledConnectionFactory
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea updated SM-1964:
--------------------------------
Attachment: smx-1964.patch
> JMS Flow only uses one connection even with a PooledConnectionFactory
> ---------------------------------------------------------------------
>
> Key: SM-1964
> URL: https://issues.apache.org/activemq/browse/SM-1964
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.3.2
> Reporter: Hadrian Zbarcea
> Fix For: 3.3.3
>
> Attachments: smx-1964.patch
>
>
> The AbstractJMSFlow uses only one connection for routing. It should take advantage of a connection pool if that's the case, but there is a bit of an edge case where this is actually a more severe issue.
> If the flow is defined such that:
> * during the flow messages are produced and send back to a queue and
> * a failover transport is used (which uses a MutexTransport internally) and
> * the broker where we enqueue is slow
> then the producer will wait for the slow broker, but in the meantime will hold the mutex, preventing all the consumers in all the threads to consume which will lead (potentially) to queues filling up on the broker and pretty much everything grinding to a halt.
> Proposed patch to follow shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.