powered by Jive Software

Threads and Scalability

I was thinking that maybe the packet listeners and keep alive threads can be shared among connections. Doing AwfulMath TM tells me that scalability would be improved by a factor of 3/5 if it were possible (that is 3 threads less per connection out of 5). In other words, Smack would create 2 threads per connection plus 2 additional threads (one packet listener and the keep alive task).

This doesn’‘t require dealing with non-blocking I/O, so the API won’‘t need to be changed. Anybody gave this a thought and found out it couldn’'t be done, or maybe I should give it a try?

P.S.: I found a related post here (http://www.jivesoftware.org/forums/thread.jspa?threadID=12711), but it’'s been archived, so I started a new one.

I’‘d have to think carefully about sharing packet listener threads, but it’'s a great idea to share the keep-alive thread.

When I first wrote Smack, it was optimized for there only being a couple of Smack connections per VM. However, lots of people (including us) are now doing many connections per VM so these types of changes are a very good idea.

I’'ve filed SMACK-34 about these changes.

Thanks,

Matt

I’'ve given the subject of sharing keepalive tasks a bit more thought. I think that they could (and should) be implemented in the packet reader thread. The way I do it in my current application is like this:

try{

socket.setSoTimeout(60000); // One minute, but we might want to use more or less depending on other issues.

} catch (…) {}

while (!isFinished()) {

try {

read(…);

timeouts = 0;

} catch (SocketTimeoutException) {

timeouts++;

if (timeouts >= 5) { // 5 minutes.

// The server’‘s connection probably died. Could be ours, too, but the TCP stack didn’'t tell us. In any case, we should formally disconnect.

closeConnection();

} else {

sendKeepAlive();

}

} catch (…) {}

}

I’‘m sure you get the idea, even if Smack’‘s I/O is handled by xpp3 as far as I can tell. I don’‘t know about XMPP, but in my application it’‘s not necessary to send keep-alives if you’‘re receiving data but not sending. It should be very easy to add an additional conditions if that’‘s not the case with XMPP. I think it’'s easier to implement something like this than the single thread solution and it allows for some extra flexibility (and better responsability separation).

By the way, am I the only one not getting e-mails for his watched threads?