JMS services and threading

[ant elder <an...@gmail.com>]

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

Re: JMS services and threading

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> ant elder wrote:
> [snip]
>> If the request message is part of a transaction when would we expect the
>> transaction to be committed or rolled back - when the consumer starts the
>> worker thread or after the service has been invoked on the worker thread?
>>
>>    ...ant
> 
> After.
> 

Following up after more thinking:

"After", and that means that spawning threads will not work with 
transactions.

Don't most JMS users want transactions as well?
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: JMS services and threading

[Jean-Sebastien Delfino <js...@apache.org>]

ant elder wrote:
[snip]
> If the request message is part of a transaction when would we expect the
> transaction to be committed or rolled back - when the consumer starts the
> worker thread or after the service has been invoked on the worker thread?
> 
>    ...ant

After.

-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: JMS services and threading

[Simon Laws <si...@googlemail.com>]

On Jan 23, 2008 12:22 PM, ant elder <an...@apache.org> wrote:

> On Jan 22, 2008 2:09 PM, Simon Laws <si...@googlemail.com> wrote:
>
> > snip...
> >
> > >
> > > 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.
> > >
> >
> > Not sure I understand this para. If the consumer starts processing the
> > message shouldn't we consider that it has been successfully delivered.
> > Processing it may cause errors but these should be application errors
> that
> > in the @OneWay case presumably get written to a log or when the
> operation
> > is
> > not one way are put in a return message and sent back to the reply to
> > address.
> >
> > Simon
> >
>
>
> If the request message is part of a transaction when would we expect the
> transaction to be committed or rolled back - when the consumer starts the
> worker thread or after the service has been invoked on the worker thread?
>
>   ...ant
>
>   ...ant
>

It depends what you mean by transaction. From your note I'm guessing you are
looking at the case of an operation that is not @OneWay and where a managed
transaction context flows with the incomming message and it is expected that
the business operation runs within this transaction context
(propogatesTransaction?). Does that sound right?

As the transaction spans more than one component I expect you are looking at
the global transaction case. I wouldn't expect this to be committed or
rolled back until all of the service operations that are part of the
transaction have completed.

The issue you are up against is that the interaction with the component in
question has ceased to be strictly synchronous at the service end. I would
argue that, given the code as it is now, it is still synchronous at the
client end. I.e. the client will not continue executing until it receives a
response or error message via the replyTo address (Not sure what happens
with void return though - need to be careful in this case). In this respect
the SCA runtime where the transaction originated is still free to commit or
rollback the transaction based on the response from the original operation.

If the service that you are concerned with is not part of a global
transaction but has it's own local transaction then SCA can only commit or
roll back the local transaction once the message has completed ("after the
service has been invoked on the worker thread"). The client will still wait
until this has happened though so we ensure that the client will not fall
into the trap of trying to read uncommitted data.

Simon

Re: JMS services and threading

[ant elder <an...@apache.org>]

On Jan 22, 2008 2:09 PM, Simon Laws <si...@googlemail.com> wrote:

> snip...
>
> >
> > 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.
> >
>
> Not sure I understand this para. If the consumer starts processing the
> message shouldn't we consider that it has been successfully delivered.
> Processing it may cause errors but these should be application errors that
> in the @OneWay case presumably get written to a log or when the operation
> is
> not one way are put in a return message and sent back to the reply to
> address.
>
> Simon
>


If the request message is part of a transaction when would we expect the
transaction to be committed or rolled back - when the consumer starts the
worker thread or after the service has been invoked on the worker thread?

   ...ant

   ...ant

Re: JMS services and threading

[Simon Laws <si...@googlemail.com>]

snip...

>
> 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.
>

Not sure I understand this para. If the consumer starts processing the
message shouldn't we consider that it has been successfully delivered.
Processing it may cause errors but these should be application errors that
in the @OneWay case presumably get written to a log or when the operation is
not one way are put in a return message and sent back to the reply to
address.

Simon