I've checked in a tentative implementation on
https://svn.jboss.org/repos/messaging/branches/Branch_Experimental_JBMESS...
The essence of change is that I introduces a new type, SerialExecutor, whose contract
guarantees tasks execution in the order in which they were submitted, regardless of how
many threads execute those threads in background. The new type comes with several
implementations: QueuedSerialExecutor which is essentially your QueueExecutor, a new
PooledSerialExecutor, whose instances can share a common pool of threads and some other
stubs (DirectSerialExecutor, etc.). Plus a whole bunch of tests.
Everything that previously was a concrete QueuedExecutor now is a generic SerialExecutor,
whose implementation is interchangeable, depending on configuration. Your
NamedThreadQueueExecutor is now a SerialExecutor too, so it can be used as a possible
implementation.
I tried to run the tests (ant clean; ant jar; cd tests; ant) and they hang, so I don't
have a "before" snapshot:
[junit] TEST org.jboss.test.messaging.jms.selector.SelectorTest(Remote-bisocket)
FAILED
... and it gets stuck here.
Things still that need to be done:
- Currently, the shared PooledExecutor is hardcoded into ServerPeer. I need to add a
configuration interface that specifies at least the maximum number of threads.
- I only modified the server-side session endpoints to use it. I see no reason not to
share the thread pools with the client-side delegates, if they live in the same VM.
- If you decide to merge this branch into the stable on and go with this extension in
production, I need to really stress the implementation of PooledSerialExecutor to make
sure it will hold in production.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157572#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...