You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Martin Serrano (Created) (JIRA)" <ji...@apache.org> on 2012/02/15 22:05:00 UTC
[jira] [Created] (AMQ-3720) ActiveMqMessageConsumer should have a
blocking message wait that does not require Session synchronization
ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization
---------------------------------------------------------------------------------------------------------
Key: AMQ-3720
URL: https://issues.apache.org/jira/browse/AMQ-3720
Project: ActiveMQ
Issue Type: Improvement
Components: JMS client
Reporter: Martin Serrano
Fix For: 5.6.0
According to the documentation I've read and response to message [posts|http://activemq.2283324.n4.nabble.com/are-session-commit-and-consumer-receive-allowed-simultaneously-in-separate-threads-tt4387875.html], I've concluded that a call to consumer.receive(long) must guard against another thread using the session the consumer was created with.
This makes it difficult to write performant code because a busy-wait idiom must be used in order to not hold a lock on session access while waiting for new messages. I've implemented a new method that will block until messages are available but does not require a session lock (it does not return any messages):
{code:java}
/**
* Waits until messages are available. Unless the caller is interrupted, there will be a message available when this
* method returns.
*/
public void waitUntilMessagesAvailable() {
while (unconsumedMessages.isEmpty()) {
synchronized (unconsumedMessages.getMutex()) {
try {
unconsumedMessages.getMutex().wait(2000); // the dispatch channel notifies when a message arrives
} catch (InterruptedException e) {
break;
}
}
}
}
{code}
I'll be happy to submit as a patch with associated unit test if there is consensus that this is needed and useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3720) ActiveMqMessageConsumer should have a
blocking message wait that does not require Session synchronization
Posted by "Timothy Bish (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208861#comment-13208861 ]
Timothy Bish commented on AMQ-3720:
-----------------------------------
I don't think that this is needed, the session commit or message acknowledge won't cause any deadlocks if called while a receive is blocked waiting as far as I can tell, the locking on the session is unnecessary.
> ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization
> ---------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3720
> URL: https://issues.apache.org/jira/browse/AMQ-3720
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Martin Serrano
> Fix For: 5.6.0
>
>
> According to the documentation I've read and response to message [posts|http://activemq.2283324.n4.nabble.com/are-session-commit-and-consumer-receive-allowed-simultaneously-in-separate-threads-tt4387875.html], I've concluded that a call to consumer.receive(long) must guard against another thread using the session the consumer was created with.
> This makes it difficult to write performant code because a busy-wait idiom must be used in order to not hold a lock on session access while waiting for new messages. I've implemented a new method that will block until messages are available but does not require a session lock (it does not return any messages):
> {code:java}
> /**
> * Waits until messages are available. Unless the caller is interrupted, there will be a message available when this
> * method returns.
> */
> public void waitUntilMessagesAvailable() {
> while (unconsumedMessages.isEmpty()) {
> synchronized (unconsumedMessages.getMutex()) {
> try {
> unconsumedMessages.getMutex().wait(2000); // the dispatch channel notifies when a message arrives
> } catch (InterruptedException e) {
> break;
> }
> }
> }
> }
> {code}
> I'll be happy to submit as a patch with associated unit test if there is consensus that this is needed and useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-3720) ActiveMqMessageConsumer should have a
blocking message wait that does not require Session synchronization
Posted by "Timothy Bish (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3720.
-----------------------------
Resolution: Not A Problem
There doesn't appear to be an issue with the code here, the user if locking on session in two different threads which will of course lead to deadlock if the consumer is not currently being dispatched any messages.
> ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization
> ---------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3720
> URL: https://issues.apache.org/jira/browse/AMQ-3720
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Martin Serrano
> Fix For: 5.6.0
>
>
> According to the documentation I've read and response to message [posts|http://activemq.2283324.n4.nabble.com/are-session-commit-and-consumer-receive-allowed-simultaneously-in-separate-threads-tt4387875.html], I've concluded that a call to consumer.receive(long) must guard against another thread using the session the consumer was created with.
> This makes it difficult to write performant code because a busy-wait idiom must be used in order to not hold a lock on session access while waiting for new messages. I've implemented a new method that will block until messages are available but does not require a session lock (it does not return any messages):
> {code:java}
> /**
> * Waits until messages are available. Unless the caller is interrupted, there will be a message available when this
> * method returns.
> */
> public void waitUntilMessagesAvailable() {
> while (unconsumedMessages.isEmpty()) {
> synchronized (unconsumedMessages.getMutex()) {
> try {
> unconsumedMessages.getMutex().wait(2000); // the dispatch channel notifies when a message arrives
> } catch (InterruptedException e) {
> break;
> }
> }
> }
> }
> {code}
> I'll be happy to submit as a patch with associated unit test if there is consensus that this is needed and useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3720) ActiveMqMessageConsumer should have a
blocking message wait that does not require Session synchronization
Posted by "kimm king (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209116#comment-13209116 ]
kimm king commented on AMQ-3720:
--------------------------------
JMS Specification defines that the session is not supporting concurrent consumer in multi-thread,
It means that only one message on the same queue will be to delivery in a session at the same time.
But you can use multi-session for multi-threads.
> ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization
> ---------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3720
> URL: https://issues.apache.org/jira/browse/AMQ-3720
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Martin Serrano
> Fix For: 5.6.0
>
>
> According to the documentation I've read and response to message [posts|http://activemq.2283324.n4.nabble.com/are-session-commit-and-consumer-receive-allowed-simultaneously-in-separate-threads-tt4387875.html], I've concluded that a call to consumer.receive(long) must guard against another thread using the session the consumer was created with.
> This makes it difficult to write performant code because a busy-wait idiom must be used in order to not hold a lock on session access while waiting for new messages. I've implemented a new method that will block until messages are available but does not require a session lock (it does not return any messages):
> {code:java}
> /**
> * Waits until messages are available. Unless the caller is interrupted, there will be a message available when this
> * method returns.
> */
> public void waitUntilMessagesAvailable() {
> while (unconsumedMessages.isEmpty()) {
> synchronized (unconsumedMessages.getMutex()) {
> try {
> unconsumedMessages.getMutex().wait(2000); // the dispatch channel notifies when a message arrives
> } catch (InterruptedException e) {
> break;
> }
> }
> }
> }
> {code}
> I'll be happy to submit as a patch with associated unit test if there is consensus that this is needed and useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira