Hi All, I think that we may have stumbled across a potential memory/resource leak.
We have one particular set up where we have a C++ producer client (using qpid::client - don't ask, it's a long story.....) this writes to a 0.8 broker hosted on the same server. That broker is then federated via a queue route to amq.match on another (0.8) broker. The queue route is a source route set up via qpid-route -s
We've been having all sorts of fun and games with respect to performance, which we've narrowed down to some dodgy networking.
However one of the other effects that we've noticed is that the broker co-located with the producer client eats memory. The queue for the queue route is 1GB but qpidd eventually grows to ~35GB and sends the whole set up into swap.
So with respect to the network problem we're suspecting a dodgy switch somewhere, what is interesting is that when we checked with ethtool the NIC was reporting half duplex had been negotiated - ouch!!! hence why we suspect a dodgy switch somewhere.
Now when the NIC was explicitly set to 100 base/T full duplex our performance rocketed and the broker on the producer system appears (touch wood) to have stable memory performance.
What I'm suspecting is that the dodgy network link has been causing connection drop-outs and the broker is automatically reconnecting (logs are confirming this) and I'm thinking that there is a resource leak somewhere during the reconnection process.
Is this behaviour that anyone else has experienced. I realise 0.8 is pretty old but a lot of our end to end system isn't under my control, if there is a known resource leak that has been fixed in a later version it might give me some ammunition to "suggest" upgrading to a more up-to-date version. I'd love to know if anyone else has seen this.
MTIA, Frase --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
