On 7/24/07, Luis Neves <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote:
> suspend/resumeRead() is an asynchronous operation. It means message
> can be received *after* suspendRead() is called. However, once
> suspension request is processed by SocketIoProcessor, no more message
> will be received.
>
> Do we need TrafficFuture or something similar for more fine-grained
> control?
humm... perhaps.
I've been experimenting to try to find a way to solve my problem and I've found
that if the producer sends a bunch of messages and then shuts down the
messageReceived() of the consumer keeps getting called long after the producer
is dead. It looks like the messages are held in consumer internal (Mina) Queue,
what I think would also help me in this particular case is the hability to
specify the maximum number of messages in the consumer Queue.... right? is there
anyway to do that?
I created a JIRA issue related with the problem you are describing:
https://issues.apache.org/jira/browse/DIRMINA-405
I already have checked in the fix. Please try the trunk and let me
know if it does the job for you. I changed ProtocolCodecFilter not to
fire messageReceived event and to hold decoded messages until read is
resumed.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
