Xiaoka Notes

Roster Versioning in jabberd2

2010-12-30T10:49:00Z

Thanks to the encouragement from Prosody Team, I spent 2 hours and implemented XEP-0237 Roster Versioning in jabberd2. The code is in jabberd2 SVN repository.

Unfortunately the only client supporting XEP-0237 is Gajim Trunk.

Roster Versioning in jabberd2 ©, .

jabberd2 packet throttling in action

2010-12-30T10:49:00Z

Today I saw jabberd2 packet throttling in action and nicely visualized. There is a visible 16 pkt/s (64 stanzas per 4 seconds) cutoff on the following graph:

jabberd2 packet throttling in action ©, .

Transport clustering in jabberd2

2010-12-30T10:49:00Z

The added value feature of clustering changes in jabberd2 is a possibility to multiplicate not only Session Manager component, but also components connected with XEP-0114 component protocol. Namely: Transports to other networks.

Component protocol connections differ from jabberd2 components that the hash used for selecting component instance to route to is computed using a ‘from’ address, not ‘to’ address. This means that the server (and s2s) userbase is distributed amongst the components (evenly).

I am currently running several clustered transports with no changes to the transport code. Pretty neat. :-)

Transport clustering in jabberd2 ©, .

Clustering for jabberd2

2010-12-30T10:49:01Z

The largest problem for large jabberd2 deployments is a single-process, single-threaded Session Manager.
Being single-threaded means that it can process only one XMPP packet at a time. More importantly, when it waits for some data (from the storage mostly) it does not process any other packets.

One possible solution would be to rewrite the SM to be multi-threaded. And I do mean rewrite – the way it is designed now, would mean rewrite (or reassembly) from scratch.

Other possible solution is to make the SM multi-processed. This means a possibility to launch many Session Manager instances to service one XMPP domain. This would balance processing load between many processes (possibly machines) and spread storage load on many separate DB connections.

Most server implementation approach this with a separate ‘clustering’ component, which tracks which session component is handling which user.
In case of jabberd2 I think it is not necessary. We already have the all decision making overseer – the router component.

I just committed to SVN trunk a router version, that handles many SM and/or external components (i.e. transports) instances for one XMPP domain. Router selects the destination instance using a hash of user JID (receiver in case of SM instances, sender in case of external components). This is an approach that most clustering HTTP deployments use, which select the web server using session-id hash.

I’m running clustered jabberd2 on Chrome.pl with no problems.

Virtual domains for jabberd2

2010-12-30T10:49:01Z

One of jabberd2 annoyances was its requirement to run one SM instance for every serviced domain. I already did some work for dynamic jabberd2 configuration introducing default host option in c2s.xml to remove requirement of restarting C2S every time one adds new serviced domain. But it still required launching separate SM process instance.

Today I committed virtual domains support changes to SVN branch http://codex.xiaoka.com/svn/jabberd2/branches/vhosts which allows you to configure more than one serviced domain in only one SM instance.
I successfully configured 3 domains in one SM instance and was able to talk between these 3 and one another in second SM process. All 4 connected to one Router process instance.

Unexpectedly it was pretty simple – it took me only ~6h. to get it working. :-)

Of course all domains serviced in one SM process have identical configuration. If you need domains with different configuration, you need to create another sm.xml and launch separate SM process for them.

The SVN vhosts branch changes need some polishing and testing. I would appreciate if you tried these and tell me what you think.