You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (Closed) (JIRA)" <ji...@apache.org> on 2012/02/16 21:56:59 UTC

[jira] [Closed] (AMQ-3720) ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization

     [ 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