powered by Jive Software

Problem with ChatManager logic with thread IDs


we have the following scenario:

User A and User B are logged in to Openfire.

User A creates a Chat with the ChatManager, which generates a ThreadID, let’s say “1” and sends a message to User 2.

The ChatManger of User 2 receives the message and creates a new Chat object based on the message, since it can’t find the chat in the “threadChats” nor in “userChats” variables.

So far it’s fine, both users chat with each other using the same ThreadID.

Now User A restarts his application and wants to continue the conversation with User 2. A new Chat object is created with a **NEW **threadID, let’s say “2”.

User B receives the message and can’t find the threadID in the threadChats variable, BUT in the userChats variable. So it takes this chat object, which has still the OLD threadID.

User B responds and writes a message to User A using the OLD threadID. User A receives the message and can’t find the old thread ID, but only the new threadID in the userChats variable.

The problem now is, that user A sends his message with threadID “2” and user 2 sends his messages with the old threadID “1”.

This is problematic because we work with the thread ID to store old conversations. If the actually same conversation uses different thread IDs we can’t relate messages properly.

I am talking about this code snippet:

connection.addPacketListener(new PacketListener() {
            public void processPacket(Packet packet) {
                Message message = (Message) packet;
                Chat chat;
                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()); // THIS IS THE PROBLEMATIC CODE.
                }                 if (chat == null) {
                    chat = createChat(message);
                deliverMessage(chat, message);
        }, filter);

Any comments on this issue?

Will it be fixed, by simply removing the fallback mechanism OR by reassigning the threadID of the message to the found chat object?

It has been a while since I looked at that code, but if memory serves correctly that should not occur. Matching to an existing user chat should only occur when there is no thread ID. If there is an id, it should always match that or create a new chat.

Ultimately, there have been conflicting requests in the past for how this should actually behave, so I believe the best solution would be to make it configurable to support a couple of different use cases.

This has already been logged as SMACK-387.

Thanks for reply!

As you can see from the code snippet, if there actually IS a thread id, but it cannot be found in the thread chats, the “old” chat object is taken from the userChats.

However, this old chat object still holds the old thread id, which results in a conversation between two users, which each use their own thread id.

Yes, I saw that when I made my last statement. It looks wrong to me as well, a new chat should be created with the new ID, only the absence of the ID should match an existing chat.

sorry - I only found this post after posting mine. There’s a diff for my backwards compatible fix in this post.