Thanks Robert!
1) I should have said I was using 0.9.4. In there I
found the CumulativeProtocolDecoder which seems to fit
the bill.
2) It's good to confirm nothing will be blocked.. That
would kind of defeat the purpose of NIO. :)
3) Hmm.. I wonder if I either I didn't explain things
properly or if Mina is doing something behind the
scenes. I'll try to explain the two ways I see it and
you let me know which one is correct.
Premise: Mina of course processes bytes in the order
they are received. So I will obviously recieve
message 1 before message 2. When my decoder receives
the message bytes it can update the IoSession with new
state information. My client can send multiple
messages before waiting for a reply from the server.
3a) (I don't think Mina does this, but correct me if I
am wrong.) After receiving message 1 Mina begins
processing message 1 in the ProtocolHandler. Even if
all data for message 2 arrives it cannot be processed
in the handler until the
ProtocolHandler.messageReceived returns. Thus the
state in IoSession will be consistent for the entire
execution of ProtocolHanlder.messageReceived while
message 1 is processed.
3b) (This is what I think Mina does, and thus one must
be wary of storing state in IoSession in this
scenario.) After receiving message 1 Mina begins
processing it in the ProtocolHandler. While _still_
processing message 1 (it takes a long time, say a
minute) all data for message 2 arrives and it is
processed by the ProtocolDecoder as well. During the
decoding of message 2 the IoSession attributes are
modified. IoSession now holds state about message 2,
not message 1. Message 1 is still being processed by
the ProtocolHandler and as a result of message 2's
arrival the IoSession attributes have changed. The
remainder of message 1 is processed with incorrect
attributes (message 2's, not message 1's). Does this
happen?
Thanks again for all your help!
Rob
--- [EMAIL PROTECTED] wrote:
---------------------------------
Hi,
1) Yes MINA does handle incomplete messages.If you
look at the decodable() method, you can return
NEEDS_DATA to indicatethat you do not have enough data
to decode the message. When more dataarrives you will
be presented with the buffer again (including the
original5000 bytes you were given originally).
2) Nothing is "blocked" assuch. If there is not enough
data nothing blocks, it just returns and thedecoder is
invoked when more data arrives on the session. The
leader/followermeans that data from different io
connections can be processed in parallel,i.e. the
socket io processor can be reading data from the
socket whileprocessing is taking place in another
thread. However note that for a givenconnection (i.e.
io session) only a single thread can be processing
thedata to ensure bytes are processed strictly in
order.
3) IoSession is the place to storeit. All bytes for a
given session are processed in order.
Robert
Rob Butler <[EMAIL PROTECTED]>
17/06/2006 03:51
Please respond to mina-dev
To: [email protected]
cc:
Subject: Keeping state across
encode/decode.
Hello all,
First off Mina looks pretty awesome. I've got a
pretty basic protocol encoder/decoder up and going in
just a few hours. Nice!
I've got several questions about Mina and I hope you
can help.
1) Does mina already handle incomplete messages behind
the scenes or do I need to do something special? FYI
- I'm extending ProtocolDecoderAdapter. So, lets say
I'm expecting 10,000 bytes to complete a message, but
so far only 5,000 have been sent by the client. If I
write:
public void decode(IoSession ioSession, ByteBuffer in,
ProtocolDecoderOutput out) throws Exception
byte[] x = new byte[10000];
in.get(x);
out.write(x);
}
Will I only get the 5,000 bytes or will Mina behind
the scenes feed the next 5,000 bytes when they arrive
so I don't have to be concerned with it?
2) Obviously if I am blocked waiting for 5,000 more
bytes from the client this thread can't do much more.
This is where the leader/follower thread pool comes
into play correct? Some background on this would be
really helpful.
3) I have a need to maintain some state gathered
during the decoding process to use during the encoding
process. At first I thought to place this into the
IoSession as an attribute, but I don't think this will
work. I think an IoSession basically maps to a client
connection, and in this case I am using TCP.
Each incoming message will have at least one outgoing
response. But my client CAN send multiple incoming
messages before I've had a chance to send a response
yet. Since the IoSession is for an entire connection
a second message could have arrived and changed the
state information in the IoSession before I've
completed my first response message. So using
IoSession attributes is out.
I supposed I could implement a command pattern in my
ProtocolHandler to keep my incoming message and all of
it's state until I generate a response. Any
suggestions on other ways to do this?
Thanks
Rob
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
This communication is for informational purposes only.
It is not intended
as an offer or solicitation for the purchase or sale
of any financial
instrument or as an official confirmation of any
transaction. All market prices,
data and other information are not warranted as to
completeness or accuracy and
are subject to change without notice. Any comments or
statements made herein
do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries
and affiliates.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
