currently I am stumbling with this warning from Smack, where our Server bulk-pushes an entire roster update.
While I agree, that smack is right here, according to this thread
and the mentioned RFC, it leaves me with the problem, that I can not even receive a callback, that this just happened, so I could react with a “roster.reload()” call or something similar.
In case, you have not really a control over the server implementation and the server works with lots of “virtual” rosters, which can be swapped entirely by setting some values in the server web-ui … how could I approach a solution here?
What is a virtual roster?
The server is a cloud based telephony system controlling many companies and you can set, what (or better: whom) you want to see by setting filters over all the people on the server, like “company grouped”, “my groups”, and the like, depending on your permissions and allowed settings.
This causes an entire roster to be published to you.
This is not a system where “subscriptions” are made, where “buddies” (in the form of subscribe/accept) are done between two explicit users (at least, this is not the normal case). It’s more like a view over the people and the server handles all that stuff for you.
Maybe I missed some interface/listener/callback where I can react on that warning so I can issue a roster.reload() call when this happens?
Smack obviously wont’ work if you use it with something different than XMPP servers. You can always hack around the issue, but the project has a strict policy to include stuff to support non-compliant behavior.
But really: Get the server fixed. Ask the vendor if you can’t do it yourself. I can’t imagine that being anything else than a trivial fix.
Well this is an xmpp server (besides many other things, like SIP)
We are talking of rosters with 2k people here… we can’t send out 2000 single updates ( to 2000 people which would sum up to FOUR MILLION update stanzas… this kills everything) when it’s possible with a single push.
A trivial fix would be, to have a callback function in the listener, something like “updateFailed” or “push failed” where I issue a single roster.reload() call.
Update
I have a feedback from the server dev team. They see the standard and we try a dev-implementation but they (the server team) and we (the frontend team) have big fears, that this is in any way a productive usable scenario in reality.
That’s way too many packets to be thrown at the clients.
I hope I can update in the next days here how this behaves in a real scenario, not in a unit test with 3 roster entries.
It most certainly is not, it possibly pretends to be one, but anything that does not adhere to the standard can not be called an XMPP server.
I am not so sure about that, ejabberd certainly is able to handle that, and I wonder if a single thready prosody would also be able.
Slightly related and keep in mind that I don’t know your use case in detail, but I think you are probably using the wrong mechanism: You may want to consider PubSub instead of (abusing?) the Roster for what you do (especially since you mentinoed that presence subscription does not play any role).