[Server-devel] ejabberd pubsub/persist issue - update

Daniel Drake dsd at laptop.org
Tue Feb 14 12:47:58 EST 2012


Just to put some notes on-record about the current ejabberd fork situation:

ejabber-2.1.10 out of the box doesn't work right with presence. A user
who connects to the network will only see the presence of users who
connect afterwards, he will not see the presence of the users who were
already on the network. The new client receives name and presence
information about the older contacts, but doesn't receive their
OLPC-specific key and buddy info (via pubsub), so doesn't display them
in Sugar.

I found that enabling mod_pubsub's last_item_cache helps a lot here
(we definitely want to do this). Now the buddy-properties
on_sub_and_presence pubsub events are received by a new client for all
existing users in the roster when he connects.

However, there are still some issues. I think there are 3 bugs, all in
different places:

1. Sugar receives those on_sub_and_presence events for neighbour
clients before it has had a chance to process the fact that those
neighbours exist, so it throws away that data (with an exception in
the logs).

2. Telepathy doesn't cache those events (as far as I can see), and I
think the events could even happen before Sugar has had a chance to
start listening.

3. In the case of 2 Sugar clients connecting together on a server,
ejabberd does seem to generate events telling each other about the
key/color info of the other client. However, there is something not
quite right with ejabberd's behaviour here. If I put 1 Sugar client on
a jabber server, then I connect my GNOME desktop (via empathy) to the
same server, monitoring the traffic between the server and my desktop
with tcpdump, the jabber server doesn't send me pubsub events about
the Sugar client's buddy-property data as it should. Must be an
ejabberd bug. Needs further investigation and then an ejabberd bug
filed upstream.

Why this worked before:
Older versions of ejabberd stored all pubsub-published information
persistently on disk, even when the publisher never asked for that (as
is true in this case).
If Sugar missed or threw away the events received upon connecting to a
network, it didn't matter because Sugar queried the server later for
the same info on a buddy-by-buddy basis. As the data was stored
consistently this worked fine, the server was able to provide the data
again. (Now that the data is not stored persistently, when Sugar makes
such queries, the server provides an empty response, which I think is


For now we will stay with ejabberd-2.1.10-1.olpc1 which readds the old
ejabberd bug that persists the pubsub data on disk.


More information about the Server-devel mailing list