Hi,
There is another client that doesn´t support yet hearbeats, jetty ( http://jeti.sourceforge.net/ )
At least not the heartbeats that wildfire requires, it was working ok with jive 2.3.
I talk to the developers and they say that jetty sends a whitespace every second as was standard for jabber clients.
They need to know what kind of heartbeat is required for wildfire or the XMPP spec, in order to change jetty.
Thanks,
Jcorreia
Personally, I vote on options #3 and #4. From what I am hearing from other people, this is not a problem with the GAIM 2.0 Beta. I haven’‘t heard anybody mention otherwise so far so this should be fixed in GAIM 2.0. But by giving the option to turn off heartbeats, that leaves open people that use a client that doesn’‘t support heartbeat. But that’'s just my opinion.
I’‘ll reiterate my comment above: if the XMPP standards require all clients to perform heartbeats, then it’‘s OK for Wildfire to require that they do so; keeping the ability to turn this off as we have now if you must use clients that don’'t conform to the standard.
If the standard doesn’‘t require the client to perform a heartbeat then Wildfire should gracefully handle those clients that don’‘t do it–and personally I don’'t include “disable the idle timeout feature via an obscure option setting” in the category of “graceful”
jcorreia mentioned above that jeti sends whitespace to the server for heartbeats and that the current wildfire version doesn’‘t seem to care about this. I’‘m curious why that is. Shouln’'t ANY valid activity (which i believe a whitespace is) from the client reset the timers?
This is very important to me because i have a custom client that we designed to do the exact same thing for keepalives.
yesno?
I just wanted to add that we’'ve tested a few clients, and found them to be broken by this mechanism (since jiveMessenger 2.3 I believe, but recently tested against wildfire 2.4 and 2.4.2)
gaim (1.5 & 2.0beta1), neos (most recent, sorry I don’'t have the version #), and the perl library POE::Component::Jabber (pcj) based pcjbot 0.5.
I’‘ve used the mechanism discussed here to change the idle timeout to 8 hours for now (setting “xmpp.client.idle” to “28800000”), and can attest that that works (well, bots die over night at that setting, but for our testing that’'s not yet an issue!)
Cheers,
Joe
Have tried adding timeouts to your sockets when you do this health check? You could set a reasonable value for how long a client has to reply and then fail the health check.
http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setSoTimeout(int)
I think that would solve your hanging in the health checking thread.
Hey Ari,
Are you referring to the TCP layer failing to inform the JVM that the socket has been dropped when sending data? I remember reading that setSoTimeout (affects #read operations) and setSOLinger (affects #close operations) had no real effect with this problem. Anyway, I think that we should be using them even though they tend to be hints to the OS.
Thanks,
– Gato