Several Activities fail to launch in crowded jabber.sugarlabs.org Neighborhood

[FGrose]

Observed on ​http://fedora.roving-it.com/SoaSv5-20110612-x86_64.iso
installed with onboard livecd-iso-to-disk.

Surf, Terminal, Log, Physics, Clock, Record, & Turtle Art failed to launch with similar error logs.

See logs attached.

Re: ​http://lists.sugarlabs.org/archive/soas/2011-June/002224.html

[walter]

Looking at the Turtle Art log, I see an error that crops up occasionally (one that I never understood), but has never prevented Turtle Art from launching. It is curious that suddenly it is fatal.

[FGrose]

This problem also occurs with Sugar in standard Fedora-15 Desktop (fully updated) when the Sugar environment is selected at login.

I noticed from the yum.log that dbus-libs was updated:

Jun 01 22:32:44 Installed: 1:dbus-libs-1.4.6-4.fc15.i686

[FGrose]

Booting SoaS 5 with a disconnected Ethernet cable eliminates this problem.

It seems the crowded jabber.sugarlabs.org Neighborhood (see the attached Neighborhood screenshot) interferes with the Activity startup process.

I noticed the same startup failures (same trackbacks) on an XO-1 with OLPC os23 when set to the jabber.sugarlabs.org Neighborhood.

[satellit]

see also same thing in

​http://wiki.sugarlabs.org/go/Talk:Community/Distributions/Fedora#testing_os871_XO-1.5
​http://dev.laptop.org/ticket/11031

[dsd]

While this is an important bug that should be investigated and fixed, in a sense I think the real problem is jabber.sugarlabs.org

This jabber server is presenting so many buddies (thousands - I think) that gabble produces more dbus traffic than you can imagine, announcing buddy status via signals etc. I'm fairly confident that this bug would not appear on saner servers.

I had a quick look at this issue anyway, and I didn't find much on my first glance. Sugar has timeouts on dbus calls going into the activity (usually SetActive), and the activity has timeouts on dbus calls going into sugar. dbus-monitor output didn't really agree with that, showing that SetActive had been called and returned, and I didn't see the failed call from the activity even appear on ths bus. Definitely worth looking further into, but the findings might be that dbus is simply too clogged up thanks to gabble noise.

[alsroot]

Replying to dsd:

While this is an important bug that should be investigated and fixed, in a sense I think the real problem is jabber.sugarlabs.org

This jabber server is presenting so many buddies (thousands - I think) that gabble produces more dbus traffic than you can imagine, announcing buddy status via signals etc. I'm fairly confident that this bug would not appear on saner servers.

As was already mentioned in #2963, it is not only jabber.sl.o issue but also a misbehaviour on the client side. It was fixed in ​http://lists.sugarlabs.org/archive/sugar-devel/2011-July/032295.html.

btw, "saner" means here not-for-development-purpose servers, because bunch of offline users in the roster (though it is partially fixed on jabber.sl.o) is because of peopel while developing sugar many times recreates jids. Eventually it is insane sugar client side behaviour.

[alsroot]

In my investigation I got feeling that this issue is gabble related (and sound like a design bug in the gabble) #2973.

This issue can't be reproducible on low traffic servers but was reproducible on previous jabber.sl.o w/ 2K of offline users in the roster (for now it behaves smoothly).

People who need to reproduce this issue need to have jabber server w/ shared roster w/ 2K+ offline buddies (and jabber.sl.o is not a good candidate for such stress testing since it started working in more-or-less production mode and would be better to avoid having lags for people who don't take part in such stress tests) and w/ gabble version from #2973.