[ 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
