messageReceived behaves correctly (one invocation for each individual
message, that's what I meant with "this is different from my first report
- messageReceived seems to behave correctly" in my earlier message).
Only messageSent() shows the reported behaviour.
Regarding advice no. 1: I am not dependent on messageSent(), I simply
discovered it when searching for the solution to my bug (as a side effect,
so to speak).
Regarding advice no. 2 ("You have to add the codec before you
bind/connect. (not in sessionCreated)"): This code is part of the
implementation since I introduced mina 0.8 to our project and I did it
that way because of the SSL filter (otherwise SSL messages were routed
through my protocol handler before the session was created and caused
exceptions, because my protocol couldn't handle them). When moving from
0.8 to 0.9 I left the code "as is" since it worked - maybe the behaviour
of the SSL filter is different now, I haven't checked that. You think I
should change it?
Greetings,
Sven
"Trustin Lee" <[EMAIL PROTECTED]> wrote on 15.09.2006 14:28:03:
> On 9/15/06, Sven Panko <[EMAIL PROTECTED]> wrote:
> >
> > Hi Trustin,
> >
> > I did some further investigation last night to narrow the problem.
Shame
> > on me, the second part of my problem (a final message in a
communication
> > session wasn't delivered until a new package was sent) was due to a
really
> > nasty bug in my code which took me three hours to detect - I hope you
> > don't mind.
>
>
> No problem. :)
>
> As for my first observation (messageSent/messageReceived is called more
> > than once): this one is still reproducible with a slight modification
(see
> > below). I created a tiny little sample program attached to this mail
which
> > (apart from some slight modifications) contains the
> > encoder/decoder/IoHandler implementation I use. It was compiled with
Java
> > 5 (Update 8) and against mina 0.9.5 (running on Win XP SP2). When you
> > start the server and afterwards the client you see, that the server
> > receives every packet one time (this is different from my first report
-
> > messageReceived seems to behave correctly). When you look at the
sysout
> > statements from the client you will see, that messageSent is called
twice
> > (on my machine) for each string it is sending over.
> >
> > Maybe the problem is related to the fact that I chose to send every
packet
> > as a header (8 bytes), followed by one or more "packets" with a size
of
> > 2KB at maximum. Since the strings are rather short (23 and 130 bytes)
I
> > invoke out.write() twice for each packet (first the header and
afterwards
> > the payload) - and I get two calls to messageSent(). In a real-case
> > scenario on our product I sent a packet of nearly 5000 byte(s), which
> > invoked messageSent four times - exactly like my code called out.write
> > (header, 2 x 2048byte packets, 904 byte packet). What is strange at
that
> > point is that messageSent() each time contains the whole message as
being
> > the data that was sent instead of only the partial packets I put into
the
> > byte buffer and "sent" via out.write()...
> >
> > Hope that helps and thanks for your time,
>
>
> Thank you for your test code! I've just checked in the fix into the
trunk.
> (1.0-SNAPSHOT). I made sure it works fine with my fix. The test code
won't
> compile with the trunk because we made some modification.
>
> 1. Remote all thread pool filters for now.
> 2. You have to add the codec before you bind/connect. (not in
> sessionCreated)
>
> But how can I reproduce the case that messageReceived is invoked
multiple
> times?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Information contained in this message is confidential and may be legally
privileged. If you are not the addressee indicated in this message (or
responsible for the delivery of the message to such person), you may not copy,
disclose or deliver this message or any part of it to anyone, in any form. In
such case, you should delete this message and kindly notify the sender by reply
Email. Opinions, conclusions and other information in this message that do not
relate to the official business of Proximity shall be understood as neither
given nor endorsed by it.
