You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2008/08/24 00:07:44 UTC
[jira] Created: (SYNAPSE-435) The JMS transport should only accept
messages when it is ready to process them
The JMS transport should only accept messages when it is ready to process them
------------------------------------------------------------------------------
Key: SYNAPSE-435
URL: https://issues.apache.org/jira/browse/SYNAPSE-435
Project: Synapse
Issue Type: Bug
Components: Transports
Affects Versions: 1.2
Reporter: Andreas Veithen
Priority: Critical
Fix For: 1.3
This issue was initially described by Hans Drexler on the Axis mailing list: http://www.nabble.com/axis2-JMS-transport-support-status--to19028249.html
While the report referred to the JMS transport version in Axis2 1.4, the current version in Synapse has the same problem: the JMS transport listener uses an asynchronous MessageListener (implemented by JMSMessageReceiver) that immediately hands the received message over to a worker pool. This means that the transport listener takes the messages as they arrive on the queue. On the other hand, the worker pool is configured with an unbound work queue. The effect is that if all threads in the pool are busy, the incoming JMS messages will be stored in memory and only processed later. This strategy has several issues:
* If the number of incoming messages is large, this can cause an out of memory condition.
* Since the transport listener uses auto acknowledge, the messages awaiting processing are lost when the server is shut down or crashes.
* The whole purpose of a message oriented middleware is to provide the necessary infrastructure to reliably queue messages between producers and consumers. Adding an additional (unreliable) in-memory queue in front of the consumer violates this pattern.
The JMS transport should therefore only accept messages when it is ready to start processing them immediately.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Resolved: (SYNAPSE-435) The JMS transport should only accept
messages when it is ready to process them
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera resolved SYNAPSE-435.
---------------------------------------
Resolution: Fixed
This issue is fixed with the new WS-Commons JMS redesign, and will be available with Synapse 1.3
> The JMS transport should only accept messages when it is ready to process them
> ------------------------------------------------------------------------------
>
> Key: SYNAPSE-435
> URL: https://issues.apache.org/jira/browse/SYNAPSE-435
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Assignee: Asankha C. Perera
> Priority: Critical
> Fix For: 1.3
>
>
> This issue was initially described by Hans Drexler on the Axis mailing list: http://www.nabble.com/axis2-JMS-transport-support-status--to19028249.html
> While the report referred to the JMS transport version in Axis2 1.4, the current version in Synapse has the same problem: the JMS transport listener uses an asynchronous MessageListener (implemented by JMSMessageReceiver) that immediately hands the received message over to a worker pool. This means that the transport listener takes the messages as they arrive on the queue. On the other hand, the worker pool is configured with an unbound work queue. The effect is that if all threads in the pool are busy, the incoming JMS messages will be stored in memory and only processed later. This strategy has several issues:
> * If the number of incoming messages is large, this can cause an out of memory condition.
> * Since the transport listener uses auto acknowledge, the messages awaiting processing are lost when the server is shut down or crashes.
> * The whole purpose of a message oriented middleware is to provide the necessary infrastructure to reliably queue messages between producers and consumers. Adding an additional (unreliable) in-memory queue in front of the consumer violates this pattern.
> The JMS transport should therefore only accept messages when it is ready to start processing them immediately.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Assigned: (SYNAPSE-435) The JMS transport should only accept
messages when it is ready to process them
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen reassigned SYNAPSE-435:
---------------------------------------
Assignee: Asankha C. Perera
Assigning this issue to Asankha since he is already working on it.
> The JMS transport should only accept messages when it is ready to process them
> ------------------------------------------------------------------------------
>
> Key: SYNAPSE-435
> URL: https://issues.apache.org/jira/browse/SYNAPSE-435
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Assignee: Asankha C. Perera
> Priority: Critical
> Fix For: 1.3
>
>
> This issue was initially described by Hans Drexler on the Axis mailing list: http://www.nabble.com/axis2-JMS-transport-support-status--to19028249.html
> While the report referred to the JMS transport version in Axis2 1.4, the current version in Synapse has the same problem: the JMS transport listener uses an asynchronous MessageListener (implemented by JMSMessageReceiver) that immediately hands the received message over to a worker pool. This means that the transport listener takes the messages as they arrive on the queue. On the other hand, the worker pool is configured with an unbound work queue. The effect is that if all threads in the pool are busy, the incoming JMS messages will be stored in memory and only processed later. This strategy has several issues:
> * If the number of incoming messages is large, this can cause an out of memory condition.
> * Since the transport listener uses auto acknowledge, the messages awaiting processing are lost when the server is shut down or crashes.
> * The whole purpose of a message oriented middleware is to provide the necessary infrastructure to reliably queue messages between producers and consumers. Adding an additional (unreliable) in-memory queue in front of the consumer violates this pattern.
> The JMS transport should therefore only accept messages when it is ready to start processing them immediately.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org