[sip-comm-dev] Re: messages are not necessarily sent in the order they were written


#1

Hey Edgar,

Have you actually experienced this issue? I am asking because I am not
certain that the different threads in ChatSendPanel could cause the
scenario you describe. ChatSendPanel's only role is to pass messages to
the protocol providers in the right order. While in theory spawning a
new thread per message could indeed leave some room for a disorder, I
don't this is all that likely given that in our specific case we have
human intervention involved in the process. In order for a later message
to leave before an earlier one the user would have to type it, send it
(with all the event dispatching that this involves), then create and
execute a new delivery thread before our first one had been allocated
any CPU time. I would have thought this quite unlikely to occur which is
why I am asking whether you've somehow witnessed it.

Once our messages reach the protocol level then ordering is entirely the
responsibility of the provider. Some providers would even spawn new
threads themselves while others won't. Either way if you are
experiencing message disordering it is more likely that this was the
fault of the corresponding provider (or server) rather than the threads
that get spawned upon hitting send.

WDYT?

Cheers,
Emil

edgarpoce@dev.java.net wrote:

···

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=724

------- Additional comments from edgarpoce@dev.java.net Mon Sep 7 01:23:14 +0000 2009 -------
proposal to fix this issue:

Bind the lifecycle of a ThreadPoolExecutor[1] instance with one single thread to
the lifecycle[2] of the component to send messages, i.e. ChatSendPanel[3], when
a message is sent[4] then we should create a Runnable and pass it to the
ThreadPoolExecutor[5] instead of creating a new thread

I haven't implemented the fix but If others agree with the proposal I volunteer
to try the idea and create a patch if it works as exected.

opinions?

[1]
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
[2]
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JComponent.html#addNotify()
and
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JComponent.html#removeNotify()
[3] net.java.sip.communicator.impl.gui.main.chat.ChatSendPanel
[4] net.java.sip.communicator.impl.gui.main.chat.ChatSendPanel#actionPerformed
[5]
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html#execute(java.lang.Runnable)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: issues-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hello Emil, I did experienced this problem only with the facebook
protocol, I'm also using jabber/gtalk and msn and had no problems. I
took a look to the code and as you say the facebook protocol
implementation spawns a new thread for each message. I think the
problem is that it doesn't wait for the response from the server
before sending the next message which probably other protocol
implementations do, or it's probably implemented in the third party
library used by SC.

In my humble opinion It seems to make sense to have a queue with only
one thread per chat session in the core because respecting the order
of the messages is a common requirement to every protocol. However, I
understand that it's not a problem for any other implementation so I
agree with you and I'll prepare a patch for the Facebook protocol
implementation.

Thanks for your feedback, I'll close the issue as invalid.

Best regards,
Edgar

···

On Tue, Sep 8, 2009 at 5:21 PM, Emil Ivov<emcho@sip-communicator.org> wrote:

Hey Edgar,

Have you actually experienced this issue? I am asking because I am not
certain that the different threads in ChatSendPanel could cause the
scenario you describe. ChatSendPanel's only role is to pass messages to
the protocol providers in the right order. While in theory spawning a
new thread per message could indeed leave some room for a disorder, I
don't this is all that likely given that in our specific case we have
human intervention involved in the process. In order for a later message
to leave before an earlier one the user would have to type it, send it
(with all the event dispatching that this involves), then create and
execute a new delivery thread before our first one had been allocated
any CPU time. I would have thought this quite unlikely to occur which is
why I am asking whether you've somehow witnessed it.

Once our messages reach the protocol level then ordering is entirely the
responsibility of the provider. Some providers would even spawn new
threads themselves while others won't. Either way if you are
experiencing message disordering it is more likely that this was the
fault of the corresponding provider (or server) rather than the threads
that get spawned upon hitting send.

WDYT?

Cheers,
Emil

edgarpoce@dev.java.net wrote:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=724

------- Additional comments from edgarpoce@dev.java.net Mon Sep 7 01:23:14 +0000 2009 -------
proposal to fix this issue:

Bind the lifecycle of a ThreadPoolExecutor[1] instance with one single thread to
the lifecycle[2] of the component to send messages, i.e. ChatSendPanel[3], when
a message is sent[4] then we should create a Runnable and pass it to the
ThreadPoolExecutor[5] instead of creating a new thread

I haven't implemented the fix but If others agree with the proposal I volunteer
to try the idea and create a patch if it works as exected.

opinions?

[1]
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
[2]
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JComponent.html#addNotify()
and
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JComponent.html#removeNotify()
[3] net.java.sip.communicator.impl.gui.main.chat.ChatSendPanel
[4] net.java.sip.communicator.impl.gui.main.chat.ChatSendPanel#actionPerformed
[5]
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html#execute(java.lang.Runnable)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: issues-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net