that sounds familiar, as in an issue that has been resolved, but I can't quickly find a corresponding jira to show that it is fixed.
It sounds like something that could be easily reproducible in a test setup. Maybe try and replicate and then try with 5.5. If the problem persists with 5.5, and there is a test case, we can quickly get to the bottom of it. On 30 June 2011 09:44, loamy <loamy.ho...@gmail.com> wrote: > Hi All > > I have a Java application (A) with 4Gb of heap using an embedded broker > (v5.3.1). I have a second application (B) also containing a broker. > > Messages are sent to broker A which auto-forwards them to broker B. We use > this setup for fault tolerance. We want to be able to continue to run A > while B is down. If B is down, messages are held in A until B is back up. > This works well. > > The configuration for A contains the following snippet: > > <networkConnectors> > <networkConnector uri="static:(tcp://<B host>:)"/> > </networkConnectors> > > I noticed recently that if B is down for an extended period of time, > application A dies with an OutOfMemoryException. > > Looking at the hprof file shows that the TransportConnector class has an > enormous number of TransportConnection instances stored in a > CopyOnWriteArrayList. > > Debugging showed that while B is down the number of TransportConnection > instances continues to climb. It then remains static when B comes back up. > And will again climb when B goes down. > > Questions: Is this a bug? Is there anything I can do to avoid this issue? > Should my broker configuration/topology be different to achieve the type of > fault tolerance I'm after? > > Many thanks > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Memory-Leak-In-TransportConnector-tp3635116p3635116.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://fusesource.com http://blog.garytully.com
