Hi Beanson,
It makes our life easier by using the message broker which decopes the
request and response side.
I don't think it's good idea to implement an executor which behavior is
bund to the queue size.
It could much easy to let the message broke reject the request when the
queue is full,
and we don't need to do other thing on the consumer side.
Willem
On Fri Feb 10 21:58:11 2012, Benson Margulies wrote:
I have another in my series of questions about JMS, threads, queues,
and executors.
I have a component which consists of a work queue and worker threads
that process that queue.
The top-level items of the system are 'documents'. Each document
contains some number of work items ('chains').
When a document arrives at the system, the chains go into the work
queue. Threads process work from the queue. Eventually, all the chains
are complete and the document is done.
Now, I'll put this into the context of CXF and JMS.
Our system distributes document-level work items via SOAP/JMS. So,
when an entire document is ready to be fed to this component,
something makes a call to a CXF client proxy, which results in a JMS
message.
A single document does not always contain enough work to keep the
component busy. So, I want to arrange something like the following
pseudocode:
start:
check queue depth
if there is room on queue, pull a document from JMS and queue work
check for completed documents
if any documents are complete, mark the corresponding JMS
messages complete
lather, rinse, repeat
It seems to me that I can approximate this by configuring a large
number of concurrent consumers, and blocking when there is no room in
the queue. I could do this with my own implementation of 'Executor'
(or ExecutorService?).
However, this seems clumsy to me, as (I think) it results in an extra
set of threads for no very good purpose, and I'd rather not even allow
a JMS message to be dispatched when there's no room.
But maybe I've misread the implications of setConcurrentConsumers and
setMaxConcurrentConsumers. Or do I need to plug in at the level of the
TaskExecutor in the JMSConfiguration? I see that the task executor is
a spring thing.
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
