I don't think the number of mdb's processing the queue affects my argument.

Lets say processing A takes 1 sec, processing B takes 1 ms.  A puts its
processed messages back on the same queue as it gets them from, dispatcher
sorts them to A, B, or Done.

if we start with the queue like

AAAAAAAA(10,000 A's)...AAAA

after 10 A's are processed the queue will look like this

AAAAAAAA(9,990 A's)...AAAABBB(10 B's)B

Since the queue is processed in order, the first B will be processed after
the last A.

With separate output queues, after 10 A's,
AAAAAAAA(9,990 A's)...AAA

and 

BBB(10 B's)

The B's can get to work right away (if you have enough hardware or the
thread scheduler lets them, presumably)

Did I miss something? It seems to me this is a direct consequence of the
"messages delivered in order" contract.

david jencks




On 2001.10.22 02:30:42 -0400 Dmitri Colebatch wrote:
> On Mon, 22 Oct 2001, David Jencks wrote:
> 
> > > I'm not sure if I quite get what you mean here.  The tasks in each
> > > message
> > > would need to be done in order, but thats only a dependency thing, I
> > > haven't really considered the situation where we have four tasks, A,
> B, C
> > > and D - with B and C requiring A's output, and D requiring B and C's
> > > output - is that what you're talking about?
> > 
> > That's one problem, I was thinking more of this one:
> > Lets say we always need tasks A and B. A is long, B is very quick.
> > 
> > All of a sudden, we get 10,000 messages - in less time than it takes to
> do
> > one A.  If the results of A are fed back into the same queue, all the
> B's
> > have to wait for every A to complete.  This is definitely not what you
> > want;-).  Feeding the output of A into a separate queue fixes this, but
> > then the advantages of your scheme become slightly diluted... you need
> > separate output queues for each task anyway, unless each message has a
> > different set of tasks why have the overhead of the dispatcher.
> 
> ahhh, ic.  ok, probably showing my greenness on MDB, but afaik you can
> specify that a JMS listener is multi-threaded if you want, its just not
> hte default.  I'm assuming that the same is possible (perhaps not
> currently) at a MDB level?
> 
> that would solve your concern, yes?
> 
> re the output queues.  I dont see such a thing.  Any output gets put in
> the method invocation object, and passed around as required.  Do you see
> a
> reason why this wouldn't work / isn't as good as multiple queues?
> 
> cheers
> dim
> 
> 
> 
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
> 
> 

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to