servicemix-dev

[Charles Souillard <Ch...@ext.bull.net>]

Hi SM dev team,

SM is delivered with activeMQ. I am doing some tests on sm-jms component 
and I found some problems...
In fact, as sm-jms only uses jms api, it may be possible to change the 
implementation.
The problem is that sm-jms is not fully jms compliant. I have identified 
at least two problems :

1) Destinations creation
2) session use

1) Destinations creation

The MultiplexingConsumerProcessor  and the MultiplexingProviderProcessor 
create destinations using session.createQueue and session.createTopic.
It is written in the jms spec that :
"This facility is provided for the rare cases where clients need to 
dynamically manipulate queue identity. It allows the creation of a queue 
identity with a provider-specific name. Clients that depend on this 
ability are not portable. Note that this method is not for creating the 
physical queue. The physical creation of queues is an administrative 
task and is not to be initiated by the JMS API."

So the sm-jms can't use any implementation. I think that there is an 
added functionnality in activeMQ which make the created destination 
available outside of the jms server... A correct use will use the admin 
api of the jms provider...

2) session use

The MultiplexingProviderProcessor is using sessions in a wrong way.
It is written in the spec that :
"A JMS Session is a single-threaded context* for producing and consuming 
messages.
* There are no restrictions on the number of threads that can use a 
Session object or those it creates. The restriction
is that the resources of a Session should not be used concurrently by 
multiple threads. It is up to the user
to insure that this concurrency restriction is met. The simplest way to 
do this is to use one thread. In the case
of asynchronous delivery, use one thread for setup in stopped mode and 
then start asynchronous delivery.
In more complex cases the user must provide explicit synchronization."

I have added traces in sm source code to verify that the thread which 
creates the session on the doStart method is not the same as the ones 
using the session to send messages for example (process method)
I think the way to do that is to close the session after the creation of 
the temporary destination (if needed) and to create producers and 
consumers just before using them...
I made the test and it is running well.

In conclusion,

1) Is it possible to integrate into sm-jms the correct source code to 
support JORAM jms implementation ? Perhaps we can perform a verification 
to know which impl we should use and then use the one of activemq or the 
one of joram (config file ?)
2) Can you update sm-jms to use sessions in a single thread ?

Any remarks is welcome !!
I can create a jira if you want and I can give you the joram code to use 
to create dynamically a queue thanks to administration (I tried it) !

Thanks,
Charles

Re: servicemix-dev

[Guillaume Nodet <gn...@gmail.com>]

Hi Charles,

For destinations creations, you should use the jndiDestinationName on
the endpoint attribute (see http://servicemix.org/servicemix-jms) to
lookup the destination in JNDI.
AFAIK, queues should be registered  in JNDI using the administrative
tools provided by your JMS broker / J2EE container.  I really do not
think the servicemix-jms should create the queue: this is the
responsability of the deployer which will create the queue and deploy
the service assembly.  In addition JORAM is LGPL and thus incompatible
with Apache policies... :(

For sessions, i think we should provide several different sets of jms
processors.  You are right that the current (and only) one uses the
same session in several threads.  We need one that is fully compliant
with the JMS spec and another one that uses jencks to allow using jca
resources outside a j2ee container.  Please raise a JIRA for this
problem.

Cheers,
Guillaume Nodet

On 4/3/06, Charles Souillard <Ch...@ext.bull.net> wrote:
> Hi SM dev team,
>
> SM is delivered with activeMQ. I am doing some tests on sm-jms component
> and I found some problems...
> In fact, as sm-jms only uses jms api, it may be possible to change the
> implementation.
> The problem is that sm-jms is not fully jms compliant. I have identified
> at least two problems :
>
> 1) Destinations creation
> 2) session use
>
> 1) Destinations creation
>
> The MultiplexingConsumerProcessor  and the MultiplexingProviderProcessor
> create destinations using session.createQueue and session.createTopic.
> It is written in the jms spec that :
> "This facility is provided for the rare cases where clients need to
> dynamically manipulate queue identity. It allows the creation of a queue
> identity with a provider-specific name. Clients that depend on this
> ability are not portable. Note that this method is not for creating the
> physical queue. The physical creation of queues is an administrative
> task and is not to be initiated by the JMS API."
>
> So the sm-jms can't use any implementation. I think that there is an
> added functionnality in activeMQ which make the created destination
> available outside of the jms server... A correct use will use the admin
> api of the jms provider...
>
> 2) session use
>
> The MultiplexingProviderProcessor is using sessions in a wrong way.
> It is written in the spec that :
> "A JMS Session is a single-threaded context* for producing and consuming
> messages.
> * There are no restrictions on the number of threads that can use a
> Session object or those it creates. The restriction
> is that the resources of a Session should not be used concurrently by
> multiple threads. It is up to the user
> to insure that this concurrency restriction is met. The simplest way to
> do this is to use one thread. In the case
> of asynchronous delivery, use one thread for setup in stopped mode and
> then start asynchronous delivery.
> In more complex cases the user must provide explicit synchronization."
>
> I have added traces in sm source code to verify that the thread which
> creates the session on the doStart method is not the same as the ones
> using the session to send messages for example (process method)
> I think the way to do that is to close the session after the creation of
> the temporary destination (if needed) and to create producers and
> consumers just before using them...
> I made the test and it is running well.
>
> In conclusion,
>
> 1) Is it possible to integrate into sm-jms the correct source code to
> support JORAM jms implementation ? Perhaps we can perform a verification
> to know which impl we should use and then use the one of activemq or the
> one of joram (config file ?)
> 2) Can you update sm-jms to use sessions in a single thread ?
>
> Any remarks is welcome !!
> I can create a jira if you want and I can give you the joram code to use
> to create dynamically a queue thanks to administration (I tried it) !
>
> Thanks,
> Charles
>