[
https://issues.apache.org/jira/browse/DIRMINA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-436.
-
> DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
>
Hi Trustin
Thanks for the info.
I found out yesterday just what you've told me now in
org.apache.mina.filter.codec.CumulativeProtocolDecoder#decode( ).
Thanks for the confirmation.
There is a bug in the http server codec example. If it receives more
than one http message in a single tcp transmi
Hi Bogdan,
On Jan 18, 2008 8:06 PM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Suppose that in a decode(IoSession session, IoBuffer in,
> ProtocolDecoderOutput out) call the IoBuffer is read and some objects
> are written to the ProtocolDecoderOutput. Suppose that the IoBuffer
>
Hello,
Suppose that in a decode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) call the IoBuffer is read and some objects
are written to the ProtocolDecoderOutput. Suppose that the IoBuffer
contains some more data, but not enough for creating another object
(to write to the ProtocolDec
On 10/22/07, mat <[EMAIL PROTECTED]> wrote:
> Is there any performance tradeoff by using MessageDecoder instead of
> CumulativeProtocolDecoder?
There's small additional overhead determining a proper MessageDecoder;
DemuxingProtocolCodecFactory iterates all registered Messag
Is there any performance tradeoff by using MessageDecoder instead of
CumulativeProtocolDecoder?
Thank you!
> DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
> NOT_OK is returned.
> --
>
> Key: DIRMINA-436
> URL: https://issues.a
DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
NOT_OK is returned.
--
Key: DIRMINA-436
URL: https://issues.apache.org/jira/browse/DIRMIN
On 6/20/07, James Apfel <[EMAIL PROTECTED]> wrote:
Hi Trustin,
the bug was on my side. I was accidently reading too many bytes from
the ByteBuffer (the message and parts of the next message). Remember:
always slice and set the limit!
Good to hear that you fixed a bug. Please come again to us
r question that comes up is if the decoders share the same
> ByteBuffer instance or rather if MINA takes care of resetting the
> ByteBuffer positions before passing it to the next MessageDecoder?
The decoders share the ByteBuffer instance, but the position is always
readjusted to make sure
x27;t.
An another question that comes up is if the decoders share the same
ByteBuffer instance or rather if MINA takes care of resetting the
ByteBuffer positions before passing it to the next MessageDecoder?
The decoders share the ByteBuffer instance, but the position is always
readjusted to
after I'm done with it.
I believe I have to as I'm seeing some very weird behavior if I don't.
An another question that comes up is if the decoders share the same
ByteBuffer instance or rather if MINA takes care of resetting the
ByteBuffer positions before passing it to the next
On 4/16/07, mat <[EMAIL PROTECTED]> wrote:
Thanks. My question is if it happens, will mina close the session?
No, it won't. MINA closes the connection only when IOException is
raised during I/O.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP
Thanks. My question is if it happens, will mina close the session?
2007/4/12, Trustin Lee <[EMAIL PROTECTED]>:
On 4/12/07, mat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> If something wrong in the MessageDecoder decodeBody(unexpected exception
> happened with no handling b
On 4/12/07, mat <[EMAIL PROTECTED]> wrote:
Hi,
If something wrong in the MessageDecoder decodeBody(unexpected exception
happened with no handling by programmer), what will mina do? Automatically
close the session?
MINA will wrap the exception with ProtocolDecoderException, and throw
i
Hi,
If something wrong in the MessageDecoder decodeBody(unexpected exception
happened with no handling by programmer), what will mina do? Automatically
close the session?
Thanks.
odable() will be called when a line end is encountered? (don't think so
=o)
1. decodable() is invoked for all registered MessageDecoders.
2. If one of them returns OK, decode() of the MessageDecoder is
invoked until it returns OK. If NOT_OK is returned, an exception is
raised. If NEED_DATA
o achieve what I expected.
>
> Yes, it's the recommended way. Please decode one message at once in
> decode() implementation. MINA will call decodable() and decode()
> again if there's more to decode.
>
> HTH,
> Trustin
> --
> what we call human nature
in
> decode() implementation. MINA will call decodable() and decode()
> again if there's more to decode.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
>
--
View this message in context:
http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9586609
Sent from the mina dev mailing list archive at Nabble.com.
Hi,
On 3/21/07, Coding Horse <[EMAIL PROTECTED]> wrote:
Hi, Trustin,
I really appreciate your wonderful explanation! Could you also shed some
light on this case when you have time:
When decodable() is called there are 3.5 complete packets of MyPacket, my
decode() implementation will take out
e if i am wrong. Thanks.
Well, what decodable() is supposed to do is to determine if this
MessageDecoder can decode the incoming data or not. Therefore, I
think this separation is useful.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
t; --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
>
--
View this message in context:
http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9584258
Sent from the mina dev mailing list archive at Nabble.com.
Sorry about the mistake I made. But somehow decodable is not very
neccessary. I can do everything in decode. If no enough packets, i just
return NULL and return MessageDecoderResult.NEED_DATA. I guess position
reverting back happenshere. Correct me if i am wrong. Thanks.
2007/3/20, Trustin Lee <[
On 3/19/07, mat <[EMAIL PROTECTED]> wrote:
I followed the Sumup Server example. In decodable, normally check the body
len. you don't have to care about the position since in decodable get()
method is to get the length of the body. The rest of bytebuffer is saved in
the instance of the AbstractMes
and return MessageDecoderResult.NEED_DATA when
it
> is not ready.
>
> My question:
> Should I care about the buffer's position/limit etc. before returning
> MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position,
> right?
>
> thx a lot!
>
r's position/limit etc. before returning
> MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position,
> right?
>
> thx a lot!
>
--
View this message in context:
http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9540526
Sent from the mina dev mailing list archive at Nabble.com.
"get" changed the buffer's position,
right?
thx a lot!
--
View this message in context:
http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9539844
Sent from the mina dev mailing list archive at Nabble.com.
Hi Wolverine,
On 12/23/06, wolverine my <[EMAIL PROTECTED]> wrote:
Hi!
I have written my own MessageDecoder and MessageEncoder.
Is it possible to unit test these two classes before the server and
client areready?
Well, it really doesn't have any differences from unit-testing
Hi!
I have written my own MessageDecoder and MessageEncoder.
Is it possible to unit test these two classes before the server and
client areready?
If yes, please give me some hints of how to unit test these codec classes.
Thank you!
29 matches
Mail list logo
