message listener threading model

[tom.baeyens]

the jms spec defines the MessageListener. does the spec also define how the threads should be assigned ? should users be able to control how many listener threads may be active concurrently ?

how is this implemented in jboss mq ?

any pointer is appreciated.

regards, tom.

[ovidiu.feodorov]

The only thing you need to be concerned when you deal with the listener is that only one thread must touch the session at one time. The session maintains its own thread that delivers messages for registered listeners. Any attempt to receive() from your own thread while a listener is registered will throw a JMSException.

Look at org.jboss.jms.client.container.ReceiverInterceptor and org.jboss.jms.client.remoting.MessageCallbackHandler (JB Messaging).

[timfox]

Chapter 8 of the JMS 1.1 spec describes optional application server facilities which allow the server to spawn multiple MessageListeners and deliver messages to them on different threads.

I believe this is implemented in JBossMQ but as yet is not implemented in JBoss Messaging.

I'm not sure how the config. params for this are configured.

[adrian.brock]

All the JMS has (it is optional) to implement is the ConnectionConsumer and Session.run().

It is the application server (MDB) that implements the ServerSessionPool/threading.

This is all becoming redundant anyway with JCA1.5 inbound messaging.

If you are trying to use JMS just to invoke an MDB, I'd recommend you write
your own inbound resource adapter for whatever domain model you have.

e.g. JBoss Messaging could expose something like Receiver,
except the "listener" is supposd to be stateless.

The current Receiver interface requires a stateful implemention with identity held
internally????? So it cannot be used as the interface to a pool like an MDB.

[ovidiu.feodorov]

org.jboss.messaging.core.Receiver?

The core refectoring that's sitting on my hardrive has changed this. The Receiver doesn't need to keep any identity internally, since handle() now returns an Acknowledgment (your 'Delivery') that can be used by the Receiver to acknowledge. The identity becomes unnecessary, and as you pointed out, saves us hashmap lookups.

package org.jboss.messaging.core;

public interface Receiver
{

 public Acknowledgment handle(AcknowledgmentHandler ackHandler, Routable routable);

}

I am not sure this is what you are talking about, though.

[adrian.brock]

I am not sure this is what you are talking about, though.

It is. The receiver can now be "stateless" if it wants to be.
Which is always a less error prone programming model.