> > 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?
>
Well yes, but doing pushes from the server is whole lot less stressful on
the server.
> > 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?
>
Yes we are still keeping track of the message but once the JMSDestination
makes a routing desicion and picks a consumer to get the message, it is
removed from the JMSDestination queue and placed on the ClientConsumer
queue. If a client fails to ack a message, that message is moved from the
ClientConsumer's queue to the JMSDestination queue.
> > 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...
>
Um??? Putting in a hardcoded drop the message if non-persistent and wait if
persistent should not be bad..
The hard coded case will help clear up how we need to reorganize things so
that we can make that logic plugable.
>--jason
>
>
>
>_______________________________________________
>Jboss-development mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-development
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
