Hi Freeman,
I was looking at code and here are two main problems that we will need
to tackle.
1. By default, we create separate TemporaryQueue for repsonse so we will
need receiver per tempqueue waiting on reply. (so that many threds.)
2. to propogate the JMS response headers back we use JAXWS
responseContext which I assume is threadlocal so we need to find out how
it will react when the response goes on different thread.
If we ignore for moment point 2 we will either need to use one
TemporaryQueue for all responses if no replyDestination is defined. Also
will neeed to have separate pool of listeners for scalability.(I don't
know how the JMS callback works so will need to look into it more)
Regards,
Ulhas Bhole
Freeman Fang wrote:
Any thoughts?
Cheers
Freeman
Freeman Fang wrote:
Hi,
Currently we are using sync way for jms transport which means the
thread get blocked until response messsage is coming or the client
side timeout, see the handleResponse() method of JMSConduit? Is it
possible that we use non-block way for JMSConduit, something like
implement JMS MessageListener API? Or any special reason we need this
sync invocation for JMS conduit?
Thanks
Freeman
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
