Re: Poor design, poor performance. Better design, better performance?

in the same Spring XML. In a client-server topology, this is a highly unlikely scenario. Your producer and consumer will live in separate .war distributions. jongraf wrote: > > > Proposed design: > * client-server topology with standalone broker > * non-persistent messagi

Re: Non-persistent queue, asyncSend

Much appreciated Joe. Let me get this straight: higher throughput with persistent messaging + asyncSend vs. non-persistent messaging? It wouldn't be the same throughput? Joe Fernandez wrote: > > Non-persistent messages are, by default, sent asynchronously (a.k.a., fire > and forget). > > Ye

Non-persistent queue, asyncSend

Two questions: 1) Is asyncSend set to true by default if I am using non-persistent messaging? The line of code where this is determined is ActiveMQSession line 1670, 1680: if (sendTimeout <= 0 && !msg.isResponseRequired() && !connection.isAlwaysSyncSend() && (!msg.isPersistent() ||

Poor design, poor performance. Better design, better performance?

In an effort to keep all of the configuration within the code, my design for implementing asynchronous messaging failed our load tests. Our application was able to withstand 1400 hits per second before implementing ActiveMQ with the following model: * embedded JVM broker * non-persistent messagin

Re: Processing multiple messages in the queue at once

prefetch limit to 0, the consumer will then have to pull > each individual message from the broker. > > AFAIK, ActiveMQ does not include a timer that, when it expires, purges a > queue. What about assigning an expiration time to the message? > > Joe > http://www.ttmso

Processing multiple messages in the queue at once

Hello fellow developers, I find myself in the midst of the age-old dilemma of needing to provide scalable code where our load tests currently indicate that the code is otherwise. I am coding a message-driven POJO. Originally I implemented the queue using the Spring DefaultMessageListenerContain