Well, seeing as how this message went unanswered for so long, I decided to
crack open the source.  Might as well help all those who might have a
similar question in the future.

I'm going to call it a bug.  There's a Map in HttpTunnelServlet that maps
clientID's to BlockingQueue transport objects.  If a normal client stops
without notifying the server(which most clients do) it maintains a zombie
object referenced by this clientID.  When the client connects again, it has
a new clientId which is generated with a unique time.  That's why it's
unnoticeable with normal http client connections.  However, the map
continues to store these objects and I can see that this might(will,
actually) lead to a memory leak.

The problem becomes immediately apparent when using the http transport to
establish a network of brokers.  The clientId of a broker client is fixed
(by the name or server name).  If the broker client fails, the server never
clears this object out of the Map.  When trying to reconnect, it sees that
it has a valid object in the map and refuses the new broker client
connection.  The only way to get the client broker to connect is to change
it's name...and there's still the zombie object in the Map.

I don't see any mechanism to test for the validity of the connection.(Some
timer to say, "have I heard from this client recently...is this connection
still alive.)  It seems at the very least if a new client connection comes
in with the same clientId...the old one should be destroyed.  Also, there
should be some  process to kill the items in the map.

I'm going to try to build the source and implement a fix.  I thought I'd
share, just in case someone else might have a problem in the future.
  
Tim 



TimDog wrote:
> 
> I am using AMQ 4.1.1.  I've set the network connectors between brokers to
> use the http protocol.  Everything works great as far as transport of
> messages.
> 
> Let's say I have two brokers mutually connected over HTTP.  Broker A and
> Broker B.
> 
> Broker A goes down down unexpectedly.(A non-graceful shutdown)   When it
> tries to reconnect to Broker B, I get the following message.(Addresses
> changed to protect the innocent)
> 
> org.apache.activemq.network.DemandForwardingBridge - Network connection
> between vm://brokerA#12 and HTTP Reader http://brokerB:80 shutdown due to
> a remote error: javax.jms.InvalidClientIDException: Broker: brokerB -
> Client: NC_BrokerA_outboundBrokerA already connected
> 
> 
> It appears that the broker B never releases the connection.  When the
> broker A tries to reconnect, broker B thinks it already has a connection
> to Broker A.
> 
> This doesn't seem to happen over the TCP transport.  Only the HTTP
> transport.  My guess is that during a normal shutdown, some command comes
> over the wire to tell Broker B that Broker A is going down and releases
> the connection.
> 
> Is there a configuration for connection Timeout that I can set for the
> transports?  Or a way to get around this issue, so that I don't have to
> manually kill the HTTP connections in JMS?  Any thoughts appreciated.
> 
> Thanks!
> 
> Tim
> 

-- 
View this message in context: 
http://www.nabble.com/HTTP-Broker-Transport-Holding-Dead-Connections-tf4431815s2354.html#a12680325
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to