activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Closed) (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (AMQ-3720) ActiveMqMessageConsumer should have a blocking message wait that does not require Session synchronization
Date Thu, 16 Feb 2012 20:56:59 GMT

     [ 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

        

Mime
View raw message