[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - JBoss 2.0 Thread model

[timfox]

OOOPS! Sorry I accidentally deleted this thread while doing some forum housekeeping! :)

Here it is in an ugly form I'm afraid:

jmesnil said:
anonymous wrote : 
  | JBM 2 is using MINA as its remoting API.
  | All JMS connections and their children (session, producer, consumer) to the same JMS server use a single MINA NioSocketConnector (i.e. one single TCP socket).
  | This means that all the JMS resources associated to the same JMS server share the same MINA IoSession.
  | In turn, this means that the messages sent by 2 JMS Sessions created from the same JMS Connection are ordered globally. This is a performance-killer and less than optimal : order must be ensured at the JMS Session level only.
  | 
  | One potential solution is to use 1 MINA IoSession per JMS Session + 1 MINA IoSession for each JMS connection. 
  | This solution is simple to implement.
  | However this means having many TCP sockets open between a JMS client and a server...
  | 
  | The other solution is to introduce a customized ExecutorFilter to process MINA messages in other threads than the I/O process thread and still  ensure that messages associated to a JMS Session and its children are treated by the same thread.
  | 
  | How to implement this ExecutorFilter?
  | 
  | The filter will have a ThreadFactory.
  | When a MINA message is sent/received, we look for a thread associated to the message target (AbstractPacket.targetID).
  | We need to correlate the session ID based on this targetID (the target can be a JMS Producer or Consumer)
  | Once we got the JMS Session ID, we use it a key to look up in a Map to get a Thread in return.
  | If there is such a thread, we use it.
  | Otherwise, we get a new thread and associate it to the JMS Session ID.
  | We can use a WeakValueHashmap (from jboss-common) with the targetID as the key and the thread as the weak value.
  | 
  | Thread life cycle
  | 
  | We get a new thread when we see a new JMS Session ID.
  | However, we do not know a priori when all messages targeted to a JMS Session have been send or received.
  | We can parse all the messages to find one corresponding to closing the JMS Session but is not a good idea to have to parse every message to identify this few messages.
  | Instead, the threads can have a keep alive time (e.g. 60 seconds) before being reclaimed (and thus being removed from the WeakValueHashmap).
  | If a thread associated to a JMS Session ID is reclaimed while the Session is still open, we create a new one next time we receive a message with this ID.
  | 
  | We also need to have threads to execute JMS Connection messages.
  | 
  | ID correlation
  | 
  | For now, each JMS resources has a random UUID.
  | We need to be able to deduce a JMS Session ID from one of its children ID (Producer, Consumer, QueueBrowser).
  | Their IDs could be prepended by a JMS Session ID (e.g. <session ID>/<resource ID>).
  | Or we can add a new attribute to the Packet interface (e.g. resourceID) which will be set either to a JMS Connection ID (for JMS Connections) or a JMS Session ID (for JMS Sessions, Producers, Consumers & QueueBrowsers).
  | This resourceID will be used as the key to the WeakValueHashMap.
  | This latest solution avoid parsing text for every message but adds a bit to the message size.
  | 
  | wdyt?
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140634#4140634

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140634