ok, I think my misunderstanding of JBossMQ must be wrong. My thoughts were that in the scenario you described each "A" will be processed in turn, _but by its own thread_, so if one were to have an unlimited thread pool, then there would be minimal delay between the "A" and "B", in a more realistic scenario you would obviously be limited by hardware resources, but I think this will also apply in the multiple queue scenario you describe. I would have thought that there was one thread pool, shared by many queues. Could someone please clarify the messaging dispatching behaviour of JBossMQ? (I'll also go run a test when I get to work)..
Re delivery order, my understanding is that JMS does not guarentee order, I had assumed part of the reason for that was the scenario you describe. cheers, dim On Mon, 22 Oct 2001, David Jencks wrote: > 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 > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
