On 11/09/2007, Jodi Moran <[EMAIL PROTECTED]> wrote: > I'm having problems using the Qpid M2 Java client (JMS to AMQP) for > publishing messages in a load test. When I publish messages as quickly > as possible, the publishing client runs out of memory (no matter what > limit I set).
Ah yes, this is something we have run into before. We had developed a solution that prevented this by using a bounded queue so that the client would basically block until the queue of pending writes had free capacity. That queue was built into the I/O layer, which is based on Apache MINA. The Jira is here: https://issues.apache.org/jira/browse/DIRMINA-302. Unfortunately it appears that we haven't pushed to get it integrated yet so it isn't available. However we have this and some other performance improvements for MINA that we are aiming to get into an M2.1 release, which is a tightly scoped release scheduled for release very soon (i.e in just a few weeks after M2). > I've noticed that there is functionality in the BasicMessageProducer > that allows the user to block on writes (_waitUntilSent), but it seems > that this functionality is not even exposed via the extended interfaces > (i.e. org.apache.qpid.jms.MessageProducer or > org.apache.qpid.jms.Session) and so requires a cast to > BasicMessageProducer or to AMQSession to use. Is the only way to get > flow control in my publishing client to make use of _waitUntilSent or is > there some other way I can achieve the same effect? This was added as a quick hack to work around the probem you describe. It obviously isn't as good as the bounded queue since it reduces performance even if the broker can for most of the time keep up with the publisher. Does casting to BasicMessageProducer until we get M2.1 done cause you any particular pain? An alternative would be to use transactions and commit when you want to flush the buffer. You could commit every n messages to keep up performance but note that clients will obviously not start receiving the messages until you do the commit (i.e. it will impact latency). Do you have any other feedback on Qpid? We would be very interested in any other comments you have, particularly about how Qpid compares with other middleware and how we can improve. RG
