> When Message are placed on the JMSQueue object, they get placed on a list
> until we have a consumer that will accept the message. The deal is that
> with an async consumer (like a MDB), when he subscribes to the destination,
> we just 'turn on the message valve' allowing messages to flow to the
so if I implemented MDB functionality as a client pull (ie. dealing with the
sessions and threading myself) it would not suck up all the messages?
> consumer as they come into the JMSQueue object. The problem is that the
> ClientConsumer object queues up messages destined for the client (because
> the Destination does not want to wait for a message to be transmited). So
> if you place 1000 message on a queue, they will be waiting in the JMSObject.
> Then when you start the MDB, those messages will be moved over to the
What do you mean by moved? There is still something tracking the message on
the router still (as well as it's persistent state) right?
> queue on ClientConsumer associated with the MDB (messages will wait there
> until they are all transmited). It seems like we need to set a limit on how
> big that client-bound message queue can get.
=)
> Right here is were we can make a whole bunch of desicions and how to try to
> handle the speed vs robustness issues. If all ClientConsumer queues are
> backed up should we wait till they have space or should be drop the message
> if it is non-persistent? I say make it configurable. What other ways could
> we handel this?
How about a pluggable that could implement an adaptive algorithm, such that
we can let applications determine the trade offs. Something simple like a
min/max for starts, such that messages are absorbed by ClientConsumers until
max, then once min has reached we refill. Or a move advanced controller
could implement a speed/time ratio and vary the re-fill threshold as
desired. Could possibly re-use some pooling logic.
How easy would you estimate this is to remedy (short-term) and fix
(long-term) or perhaps they are the same...
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
