[
https://issues.apache.org/activemq/browse/AMQNET-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56379#action_56379
]
Mark Gellings commented on AMQNET-218:
--------------------------------------
I think behavior should be the same as v1.1. In v1.1 in the DispatcherThread
class, a join was done on the local thread with a timeout set. At which point
if join timed out abort is called on the local thread which delegates to the
client callback.
I think It is the responsibility of the parent thread to properly dispose of
its child threads. The parent thread should not wait indefinitely to dispose
in this case. Otherwise If there's an infinite loop in the client callback the
Service Control Manager cannot properly shutdown the process and it has to be
killed manually.
I don't think the client can respond appropriately. The client's callback has
no way of knowing it should shutdown unless abort is called on the thread.
Then abort requested is added to the state of the thread and it can properly
shutdown when detected.
if ((Thread.CurrentThread.ThreadState &
ThreadState.AbortRequested) == ThreadState.AbortRequested)
{
_log.Debug("Abort requested.");
return false;
}
I think v1.1 behavior was correct. Dispose on the session if you want to
timeout. Dispose on the message consumer if you want to wait for the client
callback to return.
> NMS session should dispose appropriately if listener delegate still
> processing message
> --------------------------------------------------------------------------------------
>
> Key: AMQNET-218
> URL: https://issues.apache.org/activemq/browse/AMQNET-218
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.2
> Reporter: Mark Gellings
> Assignee: Jim Gomes
>
> We have a unit test working with NMS 1.1 and not with NMS 1.2.
> It appears that in v1.2 on Session.Dispose the consumer thread is not aborted
> properly. If I'm processing a message say that takes 2 minutes to complete
> and try and dispose the session it waits the full two minutes.
> With v1.1 if disposing on the session, it aborted after a timeout of 30s.
> Calling dispose on the message consumer directly would behave as calling
> dispose on the session is in v1.2.
> This is a problem if the consumer runs in a windows service as the SCM errors
> out when a user tries to shut down the service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
