After looking at this further, its exactly what MDB pooling is for (afaics). I had previously said that JMS did support mutli-threading, if the client wanted it... on re-reading the spec, it basically says that the client can create multiple sessions if they desire multi-threaded receipt of messages (see 4.4.17 of the JMS spec).
So I think this would resolve the issue you raise of messages in the queue? cheers dim On Tue, 23 Oct 2001, Dmitri Colebatch wrote: > 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 > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
