No problem, thanks for the reply. We went ahead and implemented a Thrift based daemon to maintain a connection to the qpidd daemon. However we are still seeing the same memory consumption issue. As I have mentioned, the issue only arises when the qpid daemon is operating in cluster mode. Is there any place I can look for instruction on creating tests to assert what I am observing for the purpose of providing feedback? It seems that even with the less-than-ideal use pattern we have implemented, qpid should still not exhaust all the memory on a system. Also if you can point me in the right direction for the cluster code that could be consuming the memory in this fashion, I can create a patch for our internal use.
Etrik --- On Thu, 6/25/09, Gordon Sim <[email protected]> wrote: > From: Gordon Sim <[email protected]> > Subject: Re: Qpid C++ Broker memory use > To: [email protected] > Date: Thursday, June 25, 2009, 1:22 PM > Nominal wrote: > > There is no particular constraint to utilize that > particular pattern. > > We created a SWiG interface to the C++ API so we can > produce messages > > in PHP5. Naturally this has the downside of > spawning a separate php > > interpreter for every web request. The only way > to get around this > > that I can see would be to create a producer > daemon/servelet that can > > persist a connection. That being said, is there > another way to > > approach this? If, for example, the web framework we > were using was > > in Python, the same approach would be needed as well > correct (using a > > daemon)? Its not hard to switch to a daemon for > the producer if it > > will solve the issue I'm seeing. > > Apologies for the delayed response. Using a daemon will > certainly be more efficient if it is a simple change. > Providing your connections are closed though, there > shouldn't be a big problem using a connection per message. > It will as you have noted create a queue for each connection > to a clustered broker (and it would be nice to give the > application more control over this as in your case you maybe > don't need it). However the queue should be deleted as soon > as your connection is closed. > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
