activemq-dev mailing list archives

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

    [ 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

        

Mime
View raw message