processMessage not called after updated to (a)smack 4.0, possibly a bug?

Smack Smack Dev
1

Hi,

The processMessage of my MessageListener is no longer being called after I updated to asmack 4.0.

I looked at the constructor of the ChatManager and noticed that the packetListener is changed in smack 4.0.

Before 4.0 (0.8.10 to be specific), the code tries to get a Chat from the thread id obtained from the incoming message, and if it failed, it falls back to getUserChat, which will find the Chat correctly.

if (message.getThread() == null) {
                     chat = getUserChat(message.getFrom());
                }
                else {
                    chat = getThreadChat(message.getThread());
                    if (chat == null) {
                        // Try to locate the chat based on the sender of the message
                              chat = getUserChat(message.getFrom());
                    }
                }

However, after updating to 4.0, the code tries to get a Chat from the thread id of the message (a message will always have a thread id because Chat.sendMessage will always assign one to before sending), and if it fails, it will create a new Chat instead of going to getUserChat. So my processMessage is not called because a new Chat is created to deliver the message.

if (message.getThread() == null) {
                     // it's never possible to get into this branch because getThread() is never null for a chat message
                     chat = getUserChat(message.getFrom());
                }
                else {
                    chat = getThreadChat(message.getThread());                     // why is this part removed from 4.0???
                }

So in order for the method processMessage to be called, both clients communicating with each other must have the same thread id. Is this a bug or intentional?

Thanks,

Ray

2

This issue seems to be the same as https://community.igniterealtime.org/message/186323#186323

But the change is not in to (a)smack 4.0. Why is that?

3

I have a similar problem , but if i add the jid’s resource part, i can get the message.

4

So in order for the method processMessage to be called, both clients communicating with each other must have the same thread id. Is this a bug or intentional?

That is intentional and not a bug. After all a thread ID is used to identify the same chat between multiple clients.

5

See also ChatManager.setMatchMode(MatchMode).

6

Why though? So now we have to do extra work when creating Chat.

What’s wrong with the approach of the previous version?

7

Why though? So now we have to do extra work when creating Chat.
If you ignore the thread IDs anyway, then you don’t need to use a chat. You could simply send messages between the two involved entities.

What’s wrong with the approach of the previous version?
See SMACK-387

8

Thanks Flow. That answered my question.

There is still a situation where I am not sure how to best handle. Say Bob and Alice want to send a message to each other at the same time. Bob’s client creates a new Chat object with the default thread id (say B2A) and Alice’s client also creates new Chat object with a unique thread id (say A2B).

Bob sends messages with thread id B2A, but receive message with the thread id A2B (similarly for Alice). So there are two Chat objects, but actually there is only one conversation between Bob and Alice.

Before the fix, everything is taken care of in the processMessage function of the MessageListener when Bob’s client created the Chat. Now there two places (Chat objects) a message can be received from Alice, the processMessage function, and also the packetListener of the XMPP connection.

What’s the best way to consolidate all the message processing in a single place?

Solutions I can think of:

  1. Somehow create the same thread id for both clients when Bob and Alice initiated the Chat.

  2. When Bob recieved a message from Alice and if the thread id of the message is different from the Bob’s thread id, pass the same MessageListener to the new Chat.