powered by Jive Software

Possible caching/clustering issue with XEP-0191 Blocking command

I was using the implementation of XEP-0191 to block and unblock users but I ran into some issues, possibly related to clustering and/or caching.

Typical steps to reproduce:

  • Block a user using the XEP
  • (the client receives a confirmation via the stream)
  • Unblock them after a while
  • (the client receives a confirmation via the stream)
  • (that user is no longer in the blocking list, returned from Openfire)
  • Try to send them a message

Sometimes an error stanza is still returned as if the user is still blocked.

I have confirmed that after blocking the user, the database contains a privacy list item for them, denying all messages from them.

Additionally, clearing the privacy lists cache sometimes fixes the problem.

Note: I’m using clustering via hazelcast and have two nodes connected.

Thanks for reporting this. With just this information, the issue is somewhat elusive. I’ve tried to do some debugging, but didn’t really get anywhere.

I figured that being able to review the current state of the privacy lists (which hold the block list) would be a good tool to analyze this issue.

I’ve created issues OF-2108 and OF-2109 to have the current state of the privacy lists added to the admin console. I’ve also created a basic implementation, which can be found in https://github.com/igniterealtime/Openfire/pull/1733

All this does not resolve your issue, but hopefully these tools can help to further diagnose what’s going on.

Niiice! Thanks, Guus, that’s going to be really helpful in debugging this!
It will me on my list to solve that blocking issue in 1-2 weeks and I’ll get back to you if I find anything.

1 Like

FYI: the new admin console pages that let an admin look at the privacy list configuration of users was included in Openfire 4.6.0, that got released last week.

Hopefully this will help you get to the bottom of the issue.

Way ahead of you, Guus :slight_smile:
I already cherry picked your changes in my fork and gave it a try.

Now I’m relatively certain that clustering and caching are NOT the issue. The values were always consistent between the nodes. I suspect there’s a more conventional bug in IQBlockingHandler.

It seems to put incorrect values in the privacy list. I started playing around with blocking different users and saw some strange things in your new admin panel:

I started out with two blocked users.
I blocked a third one
In the admin panel I saw still two blocked users. The new one replaced one of the others
I unblocked one
The list became empty
I blocked one of the first users again. Suddenly the original two blocked users appeared in the list

I saw some logic about reordering the items and creating new default lists in IQBlockingHandler. Maybe the problem is there. I’ll debug it tomorrow.

Anyway, your new admin panel helped out a ton!!! Thanks for implementing that so fast!

1 Like

For posterity: in a chat that we had earlier we found that one problem contributing to this problem is https://issues.igniterealtime.org/browse/OF-2112