This interface was introduced due to that it was not possible to implement presence processing by implementing it as another XMPPProcessor.

Implementation using XMPProcessor was working fine for usage on single node, but this XMPPProcessor based implementation was only needed for clustered mode in which mode it wasn't working. It was my first attempt to implement this feature basing on XMPPProcessor but it was not possible, as presences in cluster mode are propagated to resources on other nodes by adhoc commands between nodes, and due to that are not processed by destination nodes local SessionManager but are handled only by SessionManagerClustered and propagated to proper connections on C2S without being processed by local XMPPProcessors on destination node!

Due to that it is not possible remove this interface and implement it the way you described.

Ok, in such a case I will look at it while I am working on the cluster code. I will try to make it completely transparent to plugins whether they work in a single or in a cluster environment.

Looks like I may never be able to work on the promised new clustering API. I am leaving this to you then, to find a better way. But for next version.

I was looking in possible way of solving this and I think we could use EventBus mechanism instead of using XMPPPresenceUpdateProcessorIfc

However right now EventBus also executes handlers for events in same threads which were used to fire event - I think there is possible same issue as with @XMPPPresenceUpdateProcessorIfc@.

Maybe it would be good to create separate thread pool for EventBus and use this pool to execute handlers of events? This way we would remove same issue as above from EventBus and then we could use EventBus instead of @XMPPPresenceUpdateProcessorIfc@.

%bmalkow - What do you think about this change? is it possible? or maybe we should have sync and async events?

Yes, I think we definitely need a separate thread pool for eventbus to avoid slowing down processing in plugins, especially presence plugin.

Done. By default it has 4 thread pool.

You can change it by

eventbus/threads[I]=10

I also added attribute to event: local="true" with it, event will not be sent to other cluster nodes (or any subscribers outside of current node).

Would this change then require both monitoring and eventbus components to be active for all future installations, or is it a separate instance of the eventbus specifically for handling presence?

I think it would require EventBus component to be active for every installation and it is already activated by deafult - I activated it by default a few days ago as it is already required for some feature provided by Tigase XMPP Server by default.

While I tried to use EventBus and DMap to replace XMPPPresenceUpdateProcessorIfc and fix MessageCarbons implementation at the same time I found few issues with that idea. I created task #3801 and subtasks for changes to EventBus required to allow us to replace XMPPPresenceUpdateProcessorIfc with EventBus.

Work is done, tested and ready.

For now it is kept in branch Task_3801 as changes from this task and subtasks were needed to be done before I could replace XMPPPresenceUpdateProcessorIfc with EventBus.

Now there is only 1 small task open for this branch so I think I will merge this feature all subtask from Task_3801 are ready.

well done.