mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Panko <Sven.Pa...@proximity.de>
Subject Re: Problem with IoHandler messageSent/messageReceived
Date Fri, 15 Sep 2006 12:40:29 GMT
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" <trustin@gmail.com> wrote on 15.09.2006 14:28:03:

> On 9/15/06, Sven Panko <Sven.Panko@proximity.de> 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.

Mime
View raw message