Debugging a problem involving MUC

Smack Smack Dev
1

I’‘m having a problem with MUC, not sure if it’‘s my problem or a bug in Smack 2.2.0 (leaning toward the latter). I don’‘t have a thorough knowledge of everything that Smack does, and I’'d like some pointers to where I should look.

I have an app that uses Smack. If I:

  1. User A (on machine A) creates MUC, invites User B to it. User B is offline.

  2. User A sends a message to the MUC.

  3. User B (on machine B) logs in. Receives and accepts MUC request.

  4. User B Receives ParticipantStatusListener events and messages.

  5. Both users leave chat.

  6. In same session, User B creates a MUC, invites User A to it.

  7. User A accepts.

  8. (Here’'s the problem) User B does NOT receive ParticipantStatusEvents.

It appears that the “User B is offline when User A creates the chat, invites B and sends the first message” part is necessary to repeat this scenario. Also appears to happen to me only when using iChat Server, I haven’'t seen it with Wildfire.

Anyway, I’‘ve checked the presenceFilter that gets created in MultiUserChat (line 2105) and after step 7 above, the presence packet is received by User B, and the presence Filters are triggered and return the appropriate response (that is, filters match). At this point, I’‘m not seeing what’‘s supposed to happen. The packet is put in a queue, and as far as I can tell, it’'s never retrieved from that queue. The appropriate listener is never notified.

So… Hhas anybody seen this sort of problem before? Any hints about how the filtering/listener mechanism works so I know where to look for issues?

Thanks.

2

I’‘m still not sure of the entire mechanism that was going on, but: I was, in a PacketListener that was listening for MUC messages, calling MultiUserChat.nextMessage(). This was hanging up the SmackListener process because there were never going to be any messages forthcoming. I don’'t know why a PacketListener registered only with XMPPCOnnection.addMessageListener got invoked when there was no message to be returned with nextMessage(), but for some reason there was. Changing this to pollMessage() fixes my problem.