On 08/04/2008, fuchsmi <[EMAIL PROTECTED]> wrote: > > This will end up in 2x20 threads. The 20 threads from the JMS queue will call > the sync version of the ThreadProcessors process function. This functions > use AsyncProcessorHelpers to call the ASync version. This would work but it > is an ugly configuration.
I'm a little confused. Is your MyHardWork sync or async? If its sync then there's just the 20 threads managed by the JMS consumer thread pool. > By the API definition "A processor is used to implement the Event Driven > Consumer and Message Translater patterns and to process message exchanges." > I think a implementation of the Message Translater with a PollingConsumer > would be useful. We have very high load Message Translater (MyHardWork()) > and we have a critical high load environment. So I really don't want to have > control over fetching from the JMS. I don't follow your issue :) If messages are scarce (there's not many of them) and they take loads of CPU to process; then pulling messages make sense - otherwise the current async model seems the best fit - letting the JMS consumption model (Springs Message Listener Container) deal with the threading -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
