Hi, How can I ensure a thread pool will be used fro onMessage?
Thanks! ----- Original Message ---- From: Daniel Kulp <[email protected]> To: [email protected] Cc: Coder One <[email protected]> Sent: Thu, April 8, 2010 7:11:27 PM Subject: Re: Threads & incomingObserver.onMessage On Thursday 08 April 2010 6:39:49 pm Coder One wrote: > Hello, > > On the destination side, is incomingObserver.onMessage(msg) supposed to > queue up the msg and have a thread pool handle the message? It's really completely up to you. Most of the destinations use the current thread and not the thread pool as it's easier and also works with thinks like transactions and such. > I noticed in > the log that, sometime, the implementation is invoked by the same thread > that called onMessage. And at other times, I see "default-workqueue-#" > with # being a number. Most likely, those are the one-ways. With one-ways, the OneWay interceptor will flip the request onto the queue so the transport can get back to process the next request and send the "accepted" code (for http), etc... There is a flag that can be set to prevent that if needed. (JMS transport sets the flag so things like JMS transactions and such can work.) Dan > Anyone knows why my thread id would show up in the log inside the function > being invoked. I expected it to be a thread with a "default-workqueue-#" > id. > > Thanks, > > public class MyDestination > extends AbstractMultiplexDestination > { > public void process(MyMessage myMessage) > { > Message cxfMsg = transform(myMessage); > > BusFactory.setThreadDefaultBus(bus); > incomingObserver.onMessage(cxfMsg); > } > } -- Daniel Kulp [email protected] http://dankulp.com/blog
