Right now JMS services use a single JMS consumer per service so requests are single threaded. We could do nothing and just live with this restriction or we could improve this by doing things such as:
1) have the consumer spawn new threads to process each request (using the existing Tuscany thread pool). One problem with that is i don't think we can't do QOS using the standard JMS APIs as once the consumer returns the message is considered successfully processed but the spawned thread may still be processing or have an exception. Note though that we don't currently support QOS option with the JMS binding. 2) In a J2EE environment we could use an MDB. That gets more complicated to implement and may require some manual configuration 3) Use a JCA adapter. I don't know so much about implementing this but i believe that would enable control of both the threading and QOS aspects. Of those (1) seems like the easiest to do right now to get concurrent requests on JMS services working but one of the other approaches is probably needed in the long term. Anyone have any comments on this or other approaches to suggest? ...ant
