On 2001.10.22 00:11:16 -0400 Dmitri Colebatch wrote: > On Sun, 21 Oct 2001, David Jencks wrote: > > > This is very interesting. As I understand your proposal, it has or can > > have a centralized facility that knows and sets a stack of tasks that > need > > to be done on each message, and puts all the messages in whatever state > of > > progress throught their task stack into the same queue. Did I get it? > > pretty much. > > > Alternatively, your message could have no knowledge about what needed > to > > happen to it, each task could put its output into a unique queue (or > one of > > several depending on the final state, e.g. ok vs error), and all the > > routing could be done by selecting which queue an mdb listens on. > > it really gets down to messaging vs typical rmi calls doesn't it? As you > mention below, javaspaces is very much what I'm talking about, isn't > it. I suppose what I was thinking was that when a task was finished, if > it needed something else done, it would specify the next task to be > done. when the dispatcher got a message with no more tasks, it would > send > it to the final destination. output would be put as attributes in the > message > > > Maybe my interpretation that your idea involves putting all the > messages > > through the same queue several times is wrong or not essential? > > I do see all messages going to the same address, mainly so that the mdb > can act as in a similar capacity to a dispatcher servlet. > > > It seems to me as if this could lead to fast steps waiting for slow > > steps, since the messages have to be delivered in order. > > 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. david jencks > > > I'm not sure what other people think, but it has always seemed to me > that > > javaspaces provide a more elegant way of doing this kind of stuff. > > However, I haven't had time yet to write a javaspace connector or find > a > > fast persistent free javaspace implementation. > > yes (o: I haven't used Javaspaces myself, but have done a _little_ bit > of > reading about it... might be time to do some more reading and doing. > > thanks for the feedback. > > 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
