You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robert Greig (JIRA)" <qp...@incubator.apache.org> on 2007/09/22 23:41:50 UTC

[jira] Created: (QPID-609) Dispatcher threads are not always killed

Dispatcher threads are not always killed
----------------------------------------

                 Key: QPID-609
                 URL: https://issues.apache.org/jira/browse/QPID-609
             Project: Qpid
          Issue Type: Bug
          Components: Java Client
    Affects Versions: M2
         Environment: Any
            Reporter: Robert Greig
            Assignee: Robert Greig


When taking a thread dump at random points during the client unit tests there are huge numbers of dispatcher threads running.

Analysis shows this is because of the potential for dispacher threads to be created after the session has been closed.

The place where the dispatcher is created is in AMQSession.confirmConsumerCancelled:

_logger.info("Dispatcher is null so created stopped dispatcher");
startDistpatcherIfNecessary(true);

To see this happening simply run the TopicSessionTest and examine the threads running after the VMBroker has been shut down.

It is not clear to me why this method could be called *after* a session has been closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (QPID-609) Dispatcher threads are not always killed

Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Ritchie updated QPID-609:
--------------------------------

    Fix Version/s: M2

> Dispatcher threads are not always killed
> ----------------------------------------
>
>                 Key: QPID-609
>                 URL: https://issues.apache.org/jira/browse/QPID-609
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M2
>         Environment: Any
>            Reporter: Robert Greig
>            Assignee: Robert Greig
>             Fix For: M2
>
>
> When taking a thread dump at random points during the client unit tests there are huge numbers of dispatcher threads running.
> Analysis shows this is because of the potential for dispacher threads to be created after the session has been closed.
> The place where the dispatcher is created is in AMQSession.confirmConsumerCancelled:
> _logger.info("Dispatcher is null so created stopped dispatcher");
> startDistpatcherIfNecessary(true);
> To see this happening simply run the TopicSessionTest and examine the threads running after the VMBroker has been shut down.
> It is not clear to me why this method could be called *after* a session has been closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (QPID-609) Dispatcher threads are not always killed

Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Godfrey closed QPID-609.
----------------------------

    Resolution: Fixed

> Dispatcher threads are not always killed
> ----------------------------------------
>
>                 Key: QPID-609
>                 URL: https://issues.apache.org/jira/browse/QPID-609
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M2
>         Environment: Any
>            Reporter: Robert Greig
>            Assignee: Robert Greig
>             Fix For: M2
>
>
> When taking a thread dump at random points during the client unit tests there are huge numbers of dispatcher threads running.
> Analysis shows this is because of the potential for dispacher threads to be created after the session has been closed.
> The place where the dispatcher is created is in AMQSession.confirmConsumerCancelled:
> _logger.info("Dispatcher is null so created stopped dispatcher");
> startDistpatcherIfNecessary(true);
> To see this happening simply run the TopicSessionTest and examine the threads running after the VMBroker has been shut down.
> It is not clear to me why this method could be called *after* a session has been closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (QPID-609) Dispatcher threads are not always killed

Posted by "Robert Greig (JIRA)" <qp...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/QPID-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529707 ] 

Robert Greig commented on QPID-609:
-----------------------------------

OK having done some more investigation of this the problem is in AMQSession.closeConsumers. That method shuts down the dispatcher first before going on to send a Basic.Cancel for each subscription.

The obvious solution is simply to move the closing of the dispatcher to the end of the closeConsumers method - unless anyone can offer a good reason why it should be shut down first?

> Dispatcher threads are not always killed
> ----------------------------------------
>
>                 Key: QPID-609
>                 URL: https://issues.apache.org/jira/browse/QPID-609
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M2
>         Environment: Any
>            Reporter: Robert Greig
>            Assignee: Robert Greig
>
> When taking a thread dump at random points during the client unit tests there are huge numbers of dispatcher threads running.
> Analysis shows this is because of the potential for dispacher threads to be created after the session has been closed.
> The place where the dispatcher is created is in AMQSession.confirmConsumerCancelled:
> _logger.info("Dispatcher is null so created stopped dispatcher");
> startDistpatcherIfNecessary(true);
> To see this happening simply run the TopicSessionTest and examine the threads running after the VMBroker has been shut down.
> It is not clear to me why this method could be called *after* a session has been closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.