[ http://jira.activemq.org/jira//browse/AMQ-497?page=comments#action_35831 ]
Rob Davies commented on AMQ-497: -------------------------------- receive() will return null if there's a concurrent close - where do you get the idea that receive() should never return null? ie. the API docs says: Returns: the next message produced for this message consumer, or null if this message consumer is concurrently closed > receive() call should throw exception when transport fails. > ----------------------------------------------------------- > > Key: AMQ-497 > URL: http://jira.activemq.org/jira//browse/AMQ-497 > Project: ActiveMQ > Type: Bug > Components: JMS client > Versions: 4.0 M4 > Reporter: Hiram Chirino > Assignee: Rob Davies > Fix For: 4.0 RC1 > > > Reported at: http://forums.logicblaze.com/posts/list/207.page > * A QueueReceiver, running the synchronous receive() call will block > indefinitely > If you have a QueueReceiver, and it's blocked on the receive() call, it > should produce an exception when the ActiveMQ server goes down. Otherwise > there is no way for that thread to come back to life. The client does produce > an async exception alert... However that is not sufficient. That handles any > of your async consumers. This is a sync consumer, it's blocked until it > returns, or fails. Your async exception routine should wake up all sync > consumers with an exception on their receive() call. The user cannot do this, > because even if he could somehow find which Thread is blocked, interrupting > the thread is not guaranteed to work. Most JMS providers throw an exception. > 3.2.1 threw an exception. Perhaps if I wrote an async exception trigger to > close the Sender, it would unblock the other thread.. However the receieve > should really throw an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira