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]
