You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Sven Panko <Sv...@proximity.de> on 2006/09/14 19:50:14 UTC
Problem with IoHandler messageSent/messageReceived
Hello all,
I am using Mina 0.9.5 in a client/server app and experience a strange
problem with my implementation of the IoHandler: whenever I send a
message, it passes my encoder just fine and log statements indicate that
the message is properly written out. After that I put a log statement in
the messageSent() method of my IoHandler implementation - but this method
gets called several times for one single message. The reverse is true for
the receiver. The message decoder reads the data correctly and logs
whenever a message was received in its entirety. After that
messageReceived is invoked several times for the same message. I don't
have a clue if that is correct but I do not think so.
My server starts like this:
SSLFilter sslFilter = new
SSLFilter(this.sslContextFactory.getServerContext());
sslFilter.setNeedClientAuth(true);
sslFilter.setWantClientAuth(true);
IoAcceptorConfig config = new
SocketAcceptorConfig();
DefaultIoFilterChainBuilder chain =
config.getFilterChain();
SocketAcceptor acceptor = new
SocketAcceptor();
ThreadPoolFilter ioThreadPoolFilter = new
ThreadPoolFilter();
ThreadPoolFilter protocolThreadPoolFilter
= new ThreadPoolFilter();
chain.addFirst("ioThreadPool",
ioThreadPoolFilter);
chain.addLast("protocolThreadPool",
protocolThreadPoolFilter);
chain.addLast("sslFilter", sslFilter);
acceptor.bind(<socketAddress>, new
GenericSessionHandler(this), config);
My clients connect to the server like this:
ThreadPoolFilter ioThreadPoolFilter = new
ThreadPoolFilter();
ThreadPoolFilter protocolThreadPoolFilter = new
ThreadPoolFilter();
// get an SSL client context
SSLFilter sslFilter = new
SSLFilter(this.sslContext.getClientContext());
sslFilter.setUseClientMode(true);
// create the session (the connector gets reused
after sessions are closed)
this.connector = new SocketConnector();
// set the timeout
((IoConnectorConfig)
connector.getDefaultConfig()).setConnectTimeout(60);
connector.getFilterChain().addFirst("ioThreadPool", ioThreadPoolFilter);
connector.getFilterChain().addLast("protocolThreadPool",
protocolThreadPoolFilter);
connector.getFilterChain().addLast("sslFilter",
sslFilter);
ConnectFuture future = connector.connect(new
InetSocketAddress(address, port, new GenericSessionHandler(this));
// wait until the connection is established
future.join();
// the connection should be established by now...
if (!future.isConnected())
throw new
CommunicationServiceException("...");
// use this session
this.session = future.getSession();
The generic session handler is the same for client and server and looks
like this:
public class GenericSessionHandler implements IoHandler {
private final Log logger =
LogFactory.getLog(GenericSessionHandler.class);
private final SessionStateListener listener;
public GenericSessionHandler(SessionStateListener ssl) {
this.listener = ssl;
}
public void sessionCreated(IoSession session) throws Exception {
ProtocolCodecFactory codec = new SimpleFactory();
session.getFilterChain().addLast("protocolFilter",
new ProtocolCodecFilter(codec));
if (logger.isDebugEnabled()) {
logger
.debug(MessageFormat
.format(
"a
new communication session was created with peer at address {0}",
session.getRemoteAddress()));
}
}
public void sessionOpened(IoSession session) throws Exception {
if (logger.isDebugEnabled()) {
logger
.debug(MessageFormat
.format(
"a
communication session was opened with peer at address {0}",
session.getRemoteAddress()));
}
this.listener.sessionCreated(session);
}
public void sessionClosed(IoSession session) throws Exception {
if (logger.isDebugEnabled()) {
logger
.debug(MessageFormat
.format(
"communication session was closed with peer at address {0} - amount of
data transferred was {1} byte(s)",
session.getRemoteAddress(), session
.getWrittenBytes()));
}
this.listener.sessionClosed(session);
}
public void sessionIdle(IoSession session, IdleStatus status)
throws Exception {
this.listener.sessionIdle(session, status);
}
private void closeSession(IoSession session) {
try {
session.close();
} catch (Exception e) {
logger.error("exception while closing session",
e);
this.listener.sessionClosed(session);
}
}
public void exceptionCaught(IoSession session, Throwable e)
throws Exception {
if (logger.isDebugEnabled()) {
logger.debug("caught exception while processing
session", e);
}
this.listener.sessionException(session, e);
closeSession(session);
}
public void messageReceived(IoSession session, Object message)
throws Exception {
if (!(message instanceof Envelope)) {
if (logger.isDebugEnabled()) {
logger.debug(MessageFormat.format(
"received unknown object
from peer: {0}", message));
}
return;
}
if (logger.isDebugEnabled()) {
logger.debug(MessageFormat.format("message
received with UID = {0} and type = {1}", ((Envelope)
message).getRequestUid(), ((Envelope) message).getType()));
}
this.listener.objectReceived(session, message);
}
public void messageSent(IoSession session, Object message) throws
Exception {
if (logger.isDebugEnabled()) {
logger.debug(MessageFormat.format("message sent
with UID = {0} and type = {1}", ((Envelope) message).getRequestUid(),
((Envelope) message).getType()));
}
}
}
(note that Envelope is the base class of all my messages and contains a
UID)
I would never have bothered to post this here because the system worked
fine for more than 4 month. But recently I upgraded to Mina 0.9.5 and
experienced another strange problem: sometimes the last message of a
communication session is received by the client when it tries to send
another message to the server. This occurs only randomly and always
affects the last message. My client is only able to receive that last
message when it sends another message - is this behaviour intended?
Sorry for the long post, but I am stuck here...
Thanks in advance,
Sven
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.
Re: [Mina 1.0] Question concerning SocketAcceptor creation and executors on a dual-processor server
Posted by peter royal <pr...@apache.org>.
On Nov 7, 2006, at 10:14 AM, Sven Panko wrote:
> After Peters remark I am still puzzled: is it better to rely on
> SocketAcceptor's default constructor (and do not specify executors/
> socket
> io processors at all) or can I go with this for the dual processor
> machine?
>
> --- snip start
> Executor executor = Executors.newCachedThreadPool();
> SocketAcceptor acceptor = new SocketAcceptor(2, executor);
> --- snip end
>
> --- quote start
> The above example will only use 3 threads from the pool.
> 1 for accepting, and 2 for the processing of existing connection.
> --- quote end
>
> And - just out of curiosity - why does MINA use exactly 3 threads
> when I
> use this construct?
>
> --- snip start
> Executor executor1 = Executors.newFixedThreadPool(10);
> SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
> --- snip end
the SocketAcceptor is going to use a certain number of threads, based
on the first parameter.
The Executor is just there for it to get the threads its going to
use. You could use a 'NewThreadExecutor()' if you don't want to worry
about pool sizing. Its an Executor implementation that just launches
a new thread.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: [Mina 1.0] Question concerning SocketAcceptor creation and executors on
a dual-processor server
Posted by Sven Panko <Sv...@proximity.de>.
First of all, Frederic and Peter, thanks for your detailed explanation!
After Peters remark I am still puzzled: is it better to rely on
SocketAcceptor's default constructor (and do not specify executors/socket
io processors at all) or can I go with this for the dual processor
machine?
--- snip start
Executor executor = Executors.newCachedThreadPool();
SocketAcceptor acceptor = new SocketAcceptor(2, executor);
--- snip end
--- quote start
The above example will only use 3 threads from the pool.
1 for accepting, and 2 for the processing of existing connection.
--- quote end
And - just out of curiosity - why does MINA use exactly 3 threads when I
use this construct?
--- snip start
Executor executor1 = Executors.newFixedThreadPool(10);
SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
--- snip end
Sven
peter royal <pr...@apache.org> wrote on 07.11.2006 16:54:53:
> On Nov 7, 2006, at 3:43 AM, Frederic Soulier wrote:
> > Example:
> > Executor executor1 = Executors.newFixedThreadPool(10);
> > SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
> > will setup 2 SocketIoProcessors sharing a thread pool of 10 threads.
> > If you have more than 10 clients connecting and sending/receiving
> > at the
> > same time you may have pbms hence why depending on the intent of your
> > app it may be better to use:
>
> actually, not exactly..
>
> the Executor parameter to the SocketAcceptor merely provides a source
> for threads. The above example will only use 3 threads from the pool.
> 1 for accepting, and 2 for the processing of existing connection.
> (The constructor that takes an Executor was added for people that are
> integrating MINA into larger systems that want to centralize thread
> creation for the entire application)
>
> I think you may be thinking of the ExecutorFilter, which does bring
> the performance implications you mention.
>
> -pete
>
>
> --
> proyal@apache.org - http://fotap.org/~osi
>
>
>
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.
Re: [Mina 1.0] Question concerning SocketAcceptor creation and executors on a dual-processor server
Posted by peter royal <pr...@apache.org>.
On Nov 7, 2006, at 3:43 AM, Frederic Soulier wrote:
> Example:
> Executor executor1 = Executors.newFixedThreadPool(10);
> SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
> will setup 2 SocketIoProcessors sharing a thread pool of 10 threads.
> If you have more than 10 clients connecting and sending/receiving
> at the
> same time you may have pbms hence why depending on the intent of your
> app it may be better to use:
actually, not exactly..
the Executor parameter to the SocketAcceptor merely provides a source
for threads. The above example will only use 3 threads from the pool.
1 for accepting, and 2 for the processing of existing connection.
(The constructor that takes an Executor was added for people that are
integrating MINA into larger systems that want to centralize thread
creation for the entire application)
I think you may be thinking of the ExecutorFilter, which does bring
the performance implications you mention.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: [Mina 1.0] Question concerning SocketAcceptor creation and
executors on a dual-processor server
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Tue, 2006-11-07 at 10:48 +0100, Sven Panko wrote:
> For SocketAcceptor (or IoAcceptor) :
> Executor executor1 = Executors.newFixedThreadPool(nbThread);
> SocketAcceptor acceptor = new SocketAcceptor(nbThread, executor1);
>
> My feeling is that it shouldn't be a newCachedThreadPool here since
> it seems it is relative to the number of SocketIoProcessors that
> the SocketAcceptor will use.
> By default (new SocketAcceptor() without arguments), it use
> a value of 16 threads and SocketIoProcessors.
> --- end quote
>
> What I do not understand is: why do I have to specify two numbers of
> threads (one during the specification of the fixed thread pool and one
> when constructing the socket acceptor)? Frederic sets both times an
> identical value, but how are they related? Or is the first argument in the
> SocketAcceptor constructor just an information how many (core) threads the
> executor will use?
Hi sven
I believe the default behaviour in MINA 1.0.0 is 1 SocketIoProcessor
with a cached thread pool.
Specifying a number of threads in:
SocketAcceptor acceptor = new SocketAcceptor(nbThread, executor1);
will dictate how many SocketIoProcessor(s) you want.
A good start is 1 for single-cpu, 2 for dual-cpus (or dual core), etc...
Basically 1 SocketIoProcessor per CPU although at some stage you need to
run performance tests to adapt your app to your hardware and see what's
best.
Specifying a number of threads in:
Executor executor1 = Executors.newFixedThreadPool(nbThread);
will dictate how many threads are in the thread pool.
Bear in mind the number of threads is fixed so if you have many clients
connecting you may have issues here.
To reproduce MINA's 1.0.0 default behaviour you need to use :
Executor executor1 = Executors.newCachedThreadPool();
because then the pool can grow if necessary.
I recommend you have a look at the Javadoc of the Java Concurrent Util
backport.
Example:
Executor executor1 = Executors.newFixedThreadPool(10);
SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
will setup 2 SocketIoProcessors sharing a thread pool of 10 threads.
If you have more than 10 clients connecting and sending/receiving at the
same time you may have pbms hence why depending on the intent of your
app it may be better to use:
Executor executor1 = Executors.newCachedThreadPool();
SocketAcceptor acceptor = new SocketAcceptor(2, executor1);
in order to allow the pool to grow if need be.
So to answer your question the two "nbThreads" value are not related.
Pls anyone on the list correct me if I'm wrong.
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
[Mina 1.0] Question concerning SocketAcceptor creation and executors on a
dual-processor server
Posted by Sven Panko <Sv...@proximity.de>.
Hello all,
I am trying to optimize a client-server application we develop for a
client of ours. We use mina 1.0 for client and server and I am uncertain
about the number of worker/processing threads for the server to service
incoming requests. Basically mina is used "only" to perform the most basic
kind of communication (i.e. read and write objects via serialization
from/to the network). After an object has been received, it is put into an
internal queue of a communication service and processed by worker threads
outside of mina's control (i.e. without using the filter chain or
anything). So, we need mina just to read and write data. I experimented
with Frederic's suggestions in the thread "[MINA 1.x] IoThreadPoolFilter &
ProtocolThreadPoolFilter". He wrote:
--- start quote
It is only my own experience, but here is my way to set
Thread Pool for several part of Mina in 1.0 :
For SocketAcceptor (or IoAcceptor) :
Executor executor1 = Executors.newFixedThreadPool(nbThread);
SocketAcceptor acceptor = new SocketAcceptor(nbThread, executor1);
My feeling is that it shouldn't be a newCachedThreadPool here since
it seems it is relative to the number of SocketIoProcessors that
the SocketAcceptor will use.
By default (new SocketAcceptor() without arguments), it use
a value of 16 threads and SocketIoProcessors.
--- end quote
What I do not understand is: why do I have to specify two numbers of
threads (one during the specification of the fixed thread pool and one
when constructing the socket acceptor)? Frederic sets both times an
identical value, but how are they related? Or is the first argument in the
SocketAcceptor constructor just an information how many (core) threads the
executor will use?
The server we use is a dual-processor Opteron machine and I am wondering
how many threads would be best to specify for the executor and socket
acceptor - should the number match the processor count? Or should it be
greater than that? When specifying nbThread = 2, the system showed some
strange behavior, letting one client work normally, but when a second
client connected he was set to wait for a minute or longer until his
request was even patched through - after setting nbThread = 8 or higher,
this did no longer occur.
By the way, all of the communication is SSL encrypted. My setup of the
server looks like this:
--- start snip
SSLFilter sslFilter = new
SSLFilter(this.sslContextFactory.getServerContext());
sslFilter.setNeedClientAuth(true);
sslFilter.setWantClientAuth(true);
IoAcceptorConfig config = new SocketAcceptorConfig();
DefaultIoFilterChainBuilder chain = config.getFilterChain();
Executor executor = Executors.newFixedThreadPool(8);
acceptor = new SocketAcceptor(8, executor);
chain.addLast("sslFilter", sslFilter);
ProtocolCodecFactory codec = new SimpleFactory();
chain.addLast("protocolFilter", new ProtocolCodecFilter(codec));
acceptor.bind(this.socketAddress, new GenericSessionHandler(this),
config);
--- end snip
Is this configuration correct thus far, or may I run into serious
performance problem when more than 30 clients connect simultaneously
(estimated count is 50 simultaneous connects at peak times)?
Thanks in advance,
Sven
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.
Re: Problem with IoHandler messageSent/messageReceived
Posted by Sven Panko <Sv...@proximity.de>.
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" <tr...@gmail.com> wrote on 15.09.2006 14:28:03:
> On 9/15/06, Sven Panko <Sv...@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.
Re: Problem with IoHandler messageSent/messageReceived
Posted by Trustin Lee <tr...@gmail.com>.
On 9/15/06, Sven Panko <Sv...@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
Re: Problem with IoHandler messageSent/messageReceived
Posted by Sven Panko <Sv...@proximity.de>.
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.
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,
Sven
"Trustin Lee" <tr...@gmail.com> wrote on 15.09.2006 05:11:34:
> Hello Sven,
>
> To summarize your problem:
>
> 1. messageReceived (or messageSent) is fired more than once for one
message.
> 2. messageReceived event sometimes contain ehe message sent to the
remote
> peer.
>
> Is this correct?
>
> Fixing this kind of problem is not really easy until you provide a
> reproduceable JUnit test case or very easy step-by-step instruction.
Could
> you please do that for us?
>
> Another option could be upgrading to the latest snapshot in our SVN
> repository, but there's no essential difference in event handling
between
> 0.9.5 and trunk.
>
> 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.
Re: Problem with IoHandler messageSent/messageReceived
Posted by Trustin Lee <tr...@gmail.com>.
Hello Sven,
To summarize your problem:
1. messageReceived (or messageSent) is fired more than once for one message.
2. messageReceived event sometimes contain ehe message sent to the remote
peer.
Is this correct?
Fixing this kind of problem is not really easy until you provide a
reproduceable JUnit test case or very easy step-by-step instruction. Could
you please do that for us?
Another option could be upgrading to the latest snapshot in our SVN
repository, but there's no essential difference in event handling between
0.9.5 and trunk.
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