I have added some comments to the referenced ticket. The roster push does work if the client does fully supports XMPP RFC, I mean the core feature see-other-host.

I think this is good enough.

Unless you have an idea how to implement it efficiently on the server side without this requirement I am rejecting the ticket.

%wojtek , %andrzej.wojcik please feel free to reopen the ticket if you are convinced you can implement it on the server side.

%kobit %wojtek This issue is not just an issue with simple roster push. Clients connected to the different cluster node that the one on which modification was made are unaware of the modified roster and are still using old roster! Moreover, if another roster change is done on a different cluster node than previous one (assuming here that clients are still connected), then previous roster version is overwritten and previous changes made on a different cluster node are lost!

This is not a good behavior. I agree that client should comply to see-other-host@, but the issue here is that @see-other-host is only triggered if and only if client opts-in by sending its bare jid in opening stream from attribute. In another case, it does not apply (Psi case).

As for the implementation, we can use EventBus and events to propagate roster changes between nodes and notify only nodes which have active user sessions to minimize overhead. The same event may trigger roster pushes as well.

I share %andrzej.wojcik sentiment. While see-other-host is part of the core it's an error condition and specification says:

The root stream element MAY contain an child element that is qualified by the stream namespace. The error child SHALL be sent by a compliant entity if it perceives that a stream-level error has occurred.

so my understanding goes that it's not mandatory to implement correct handling of all defined error conditions (especially that those are errors)

What's more, weighting on roster/roster push support vs see-other-host support the outcome is not that great (I think that Tigase software is the only one used in the open that uses it, but this requires combination of both Tigase server and our client/libraries) thus the experience for the end user is suboptimal.

As Andrzej said - we could use events to handle it (and we are already generating events for when the some user-related actions takes place, removal, various aspects of establishing session). Granted, it would be better to have more transparent handling of it within cluster, but this particular problem can be tackled with EventBus.

Ok, in such a case, go ahead with implementation. Assigning to Andrzej. Make it part of the 7.2.0/8.0.0 version release.

It was not so simple to find a good way to implement it as even with EventBus a few things were not accessible in an easy way and I need to find a way to get access to them.

Finally, I was able to access all required variables and components and implement it.

Moreover, during testing, I've found out that presence packets related to subscription sent by one of our clients connected to one node are delivered to the other client connected to the other node even though they had different to attribute! I solved it as well by applying changes in our clustering strategies (default and ACS).

The only thing which I have not tested are adhoc commands related to roster modification, but they should already work fine. However, it may be possible to adjust them to improve then and skip sending packets to other cluster nodes if it is not needed as now EventBus should deliver notifications.

Works now - thank you. There seems to be a problem with ad-hoc but I think we could ignore that for now ( %kobit ? ).