Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73017.03BA71BB"
Subject: dangling thread after shutdown broker with a managed transport
Date: Thu, 4 Jan 2007 07:43:00 -0800
Message-ID: <68B9548ED9F8A341B21CDB320655D613026FE458@mercury.nmwco.com>
Thread-Topic: dangling thread after shutdown broker with a managed transport
Thread-Index: AccwFwNvMVocx8PARJ+V96wEI+s6BA==
From: "Chris Hofstaedter" <chrish@nmwco.com>
To: <activemq-users@geronimo.apache.org>

------_=_NextPart_001_01C73017.03BA71BB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I ran into a problem in which I end up with an orphaned thread every
time I bounce a broker with a managed transport.  I realize this may not
be a big deal in many scenarios, but we may end up bouncing our broker
everytime a user changes some configuration settings in our application
and we need the app to run indefinitely.  So orphaned threads are a
concern to me.
=20
I traced it down to BrokerService.startTransportConnector().
=20
In this function, if isUseJmx() returns true, the connector is
decorated/replaced through a call to connector.asManagedConnector().
Turns out the broker never stores the reference to the newly created
managed connector anywhere.  I added transportConnectors.add(connector)
to add the new managed connector to the broker's container of connectors
and it seems to work in that all threads are shutdown cleanly even when
the transport connector is managed.
=20
Does this seem like a reasonable change and should I create a JIRA to
capture the change?

------_=_NextPart_001_01C73017.03BA71BB--