Get your Roster without blocking

Hi again,

As you probably realized by now, I’‘m working on making Smack better behaved in multi-threaded/server environments. I’‘m no Jabber wizard, most of what I know about it I learned using Smack, and I’‘m not even a Smack expert (nor close!), but I’'m eager to receive comments, questions and tips on this regard.

This patch is pretty simple, but it allows you to get the roster once it’'s been loaded and not have to block. As a bonus, using this method never gives you a null roster, in opposition to XMPPConnection.getRoster on slow connections (where loading the roster might take more than the 2 seconds blocking limit).

My server-side application pushes the roster to the user upon log-in (and subsequent modifications), so this simple modification reduced the log-in time to about a fifth. As usual, your milleage might vary.
smack-1.4.1-jkohen-rosterlistener.patch (1884 Bytes)

Note that you can do the same by registering a packet listener with the connection and listening for roster packets. But why duplicate the code in Roster and expose the protocol’'s internals when you can simply reuse?

There is one remaining problem, namely a race condition. The roster field is assigned an object in the login method, and thus the roster listener cannot be registered until this method returns. This method also calls roster.refresh, so if the roster were received before login returns and the roster listener can be registered, the event would be lost.

I created this patch to make it possible to register the roster listener before logging in. It creates a roster in the constructor and then just discards it for anonymous log-ins. What do you think?
smack-1.4.1-jkohen-rosterlistener2.patch (3129 Bytes)

I like this idea – it will provide a simple way to let clients feel more responsive. I filed a new issue (SMACK-35) to add in your patch. When I’‘m doing the integration, I’'ll try to figure out if there are any alternatives to the workaround you did in your second patch.

Thanks!

-Matt

Actually my second patch allows to add packet listeners before starting the login, thus allowing the application to snoop on the login process and also process post-login packets that might arrive before it has time to register the listener.

That’'s something I think would be nice to have anyway.

Thanks!