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.
Thanks Etrik --- On Tue, 6/16/09, Gordon Sim <[email protected]> wrote: > From: Gordon Sim <[email protected]> > Subject: Re: Qpid C++ Broker memory use > To: [email protected] > Date: Tuesday, June 16, 2009, 4:08 PM > Nominal wrote: > > Currently I am running one queue with a 15 message per > second rate on > > average, those failover queues are created and > deleted at pretty > > much the same rate. The producers are producing > at one message per > > connection/session. This seems to create a new > queue bound to the > > amq.failover exchange for each message.. I'm thinking > I may be doing > > something wrong in this regard, but I don't see > another obvious way. > > The failover queues are created for each connection, and > should be deleted when the connection is then closed. > > Producing one message per session/connection will obviously > not give the best throughput. Is there a reason you > want/have to use that pattern? > > > > --------------------------------------------------------------------- > 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]
