Thread id issue

Hi All,

Following is my scenario.

I have the following clients setup.

client1 =

client 2=

machine-A —\resource1 connected

machine-B —\resouce2 connected

machine-C —\adminResource1 connected

machine-D —\adminResource2 connected

When\adminResource1 sends a message for the first time ever to the bare jid with threadId=ABC – one of the client’s on either machine A or B receive the message successfully with all the correct details including the thread id ABC. The reply to the first message by\resource1 contains all the correct details including the corrent thread id, the correct sender jid and the correct receiver jid.

But after the first message has been received by\resource1 , all new messages coming from\resouce1 with new a new Thread Id for example DEF (As seen in the Raw Packet via Debug window) are received with the old thread id of the first message when they are received by the MessageListener’s chatCreated(Chat chat, boolean createdLocally) method.

Because of this when]\resouce1 replies to the message for all other messages after the first message, the message goes to the wrong admin client. For example if the second message received by was from\adminResource2 – the message ends up to\adminResource1 as I am thinking because the thread id being set on the outgoing message is that of the first message which was received from\adminResource1, the reply message ends up in to the wrong admin client.

Any help or pointers to solve the issue will be greatly appreciated.

This is a known issue, which I already discovered here:

The problem is, that 2 resources generate 2 different thread ids when the send a message. This is ok.

The receiver receives the first message and creates a Chat object (associated with thread “ABC”).

Then it receives the second message from the SAME bare JID (but other resource), but with thread “DEF”.

Smack can’t find DEF, so it just takes the next best Chat object assoicated with the user, which is the “ABC” Chat, but it fails to reassign the new thread to the old chat object.

This is a bug in Smack, filed here: