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?
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 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?