Privacy List might not work when using Connection Manager

Openfire Openfire Support
1

Hello,

I’'m currently experiencing some troubles with Privacy List which seems to involve how stanza are processed when using the CM.

Use case:

  1. UserA, UserB, and UserC are all online and subscribed to one another’'s presence

  2. UserA goes invisible

2.1) UserA pushes unavailable presence

2.2) UserA pushes new privacy list (block all outgoing presence)

2.3) UserA pushes available presence

  1. UserB receives unavailable presence for UserA, UserC does not

I’'ve done some few tests connecting to Openfire directly or through a CM and here are my results.

When connected to OF:

  • each client has a dedicated thread server side for processing incoming stanzas

  • stanza are read and processed one after the other (tested with debugger)

=> everything works fine there

When connected to CM:

  • CM has 5 connections (blocking io, mina is not used in that part) to OF and the

incoming traffic for each connection is handled by 5 threads

  • This mean that a stanza coming from a particular client will be randomly handled by 1

of this 25 threads.

In my test environment I’'ve setted up a CM with 1 connection and 5 threads.

Playing with the debugger I’'ve seen that the unavailable presence and the privacy list where handled in different threads.

Playing with breakpoints I’‘ve easily been able to have the privacy list set processed before the unavailable presence (meaning that eventhough I’'m invisible everybody see me as online). I think that if I try hard enough I might be able to have the presence push only to a subset of the roster.

Although, from time to time I’'ve seen some ConcurentModificationException in the logs.

org.jivesoftware.wildfire.handler.PresenceUpdateHandler.process(PresenceUpdateHa ndler.java:141)

Internal server error. Triggered by packet:

java.util.ConcurrentModificationException

at

java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)

at java.util.AbstractList$Itr.next(AbstractList.java:420)

at

org.jivesoftware.wildfire.privacy.PrivacyList.shouldBlockPacket(PrivacyList.java :101)

at

org.jivesoftware.wildfire.roster.Roster.broadcastPresence(Roster.java:612)

at

org.jivesoftware.wildfire.handler.PresenceUpdateHandler.broadcastUpdate(Presence UpdateHandler.java:258)

at

org.jivesoftware.wildfire.handler.PresenceUpdateHandler.process(PresenceUpdateHa ndler.java:109)

at

org.jivesoftware.wildfire.handler.PresenceUpdateHandler.process(PresenceUpdateHa ndler.java:153)

at

org.jivesoftware.wildfire.PresenceRouter.handle(PresenceRouter.java:92)

at

org.jivesoftware.wildfire.PresenceRouter.route(PresenceRouter.java:61)

at

org.jivesoftware.wildfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:75)

at

org.jivesoftware.wildfire.multiplex.MultiplexerPacketHandler.processPresence(Mul tiplexerPacketHandler.java:231)

at

org.jivesoftware.wildfire.multiplex.MultiplexerPacketHandler.route(MultiplexerPa cketHandler.java:177)

at

org.jivesoftware.wildfire.net.ConnectionMultiplexerSocketReader$4.run(Connection MultiplexerSocketReader.java:195)

at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:6 50)

at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

I don’‘t see an easy way to fix this and I’'m hoping that some of you might have some ideas?

2

Hi Yann,

I think you did already a comment to JM-835, that’'s once again the same thing. Wrong message order leads to unexpected behavior, and it is true for all packets, also during login / auth which may fail because of this problem.

LG

3

That’'s in part true and in part not, that it is somehow related to stanza ordering issues.

I was just expecting that when messages arrived in the wrong order they were logically processed in the wrong order by the server. (wrong ordering due to the fact that there are more that one connection between the CM and OF)

The problem I’'m experiencing here shows that even if stanza arrived in the right order there might be processed at the same time in different threads!! This can lead to a lot lot of troubles due to concurency issues and we can expect some crazy behaviours nearly everywhere.

In my opinion it’'s a serious issue