Socket Connection Failure--Presence Messages

Openfire Openfire Dev
1

We have Jive Messenger 2.1.2 running on a large corporate network and we are experiencing intermittent message (presence) delivery failures to the clients (Pandion, Gaim, etc). We experience the following on a regular basis,

1.) User A signs on

2.) User B signs on

3.) The server console shows that user B is signed on

3.) User B signs off

4.) The server console shows that user B is signed off

4.) User A never receives the ‘‘unavailable’’ presense message for user B from Jive Messenger

This problem is easily reproduced after being logged on the IM network from 30 minutes to an hour. We have verified through network packing sniffing that the presence message is never sent.

We believe the problem is related to internal firewall reconnection intervals causing “Broken Socket” errors to occur. Would it be possible to automatically reconnect to the client if the connection dies between sending messages? This could be a configurable server property e.g. “Client reconnection attempts” defaulting to 2.

Upon inspecting the server logs, we found

error log----

java.net.SocketException: Broken pipe

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(Unknown Source)

at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(Unknown Source)

at sun.nio.cs.StreamEncoder.flush(Unknown Source)

at java.io.OutputStreamWriter.flush(Unknown Source)

at java.io.BufferedWriter.flush(Unknown Source)

at org.dom4j.io.XMLWriter.flush(XMLWriter.java:244)

at org.jivesoftware.messenger.net.SocketConnection.deliver(SocketConnection.java:1 89)

at org.jivesoftware.messenger.ClientSession.deliver(ClientSession.java:287)

at org.jivesoftware.messenger.ClientSession.process(ClientSession.java:281)

at org.jivesoftware.messenger.roster.Roster.broadcastPresence(Roster.java:419)

at org.jivesoftware.messenger.handler.PresenceUpdateHandler.broadcastUpdate(Presen ceUpdateHandler.java:247)

at org.jivesoftware.messenger.handler.PresenceUpdateHandler.process(PresenceUpdate Handler.java:91)

at org.jivesoftware.messenger.handler.PresenceUpdateHandler.process(PresenceUpdate Handler.java:150)

at org.jivesoftware.messenger.PresenceRouter.handle(PresenceRouter.java:86)

at org.jivesoftware.messenger.PresenceRouter.route(PresenceRouter.java:59)

at org.jivesoftware.messenger.PacketRouter.route(PacketRouter.java:73)

at org.jivesoftware.messenger.net.SocketReadThread.readStream(SocketReadThread.jav a:227)

at org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:110)

warning log----

2005.04.08 16:08:38 Packet sent to unreachable address

2005.04.12 13:15:13 Packet sent to unreachable address

Thanks in advance…

2

Hey Micah,

Unfortunately, I don’‘t think that it is valid to create a new connection for an existing (and authenticated) session. I don’‘t know which client are you using but some clients may support a keepalive functionality so enabling the keepalive may prevent the firewall to drop the connections. Or you may try changing the firewall’'s configuration.

Regards,

– Gato

3

Gato, thanks for the reply.

The clients (Pandion and Gaim) both exibit the intermittent non-delivery of ‘‘presence’’ messages. I’‘ve decreased the keep-alive timeout in Pandion from 30 seconds to 10 seconds as an experiment and I’'m still seeing the same behavior.

What’'s interesting, is the fact that a user will instant message me and show up as offline because the client (Pandion, etc) never received the presence message when the user signed on.

The possible solutions I’'m currently pondering are

1.) modify jive messenger to periodically resend undelivered presense messages while the client is still authenticated

2.) modify the client (pandion, gaim, etc) to periodically sign out and sign back on automatically to refresh the roster

Any other suggestions? Anyone experienced this situation? I know I can’'t be the only one stuck on an unreliable network. ;o)

4

The relevant code is

  • private void deliver(Packet packet) {

if (conn != null && !conn.isClosed()) {

try {

conn.deliver(packet);

}

catch (Exception e) {

Log.error(LocaleUtils.getLocalizedString(“admin.error”), e);

// TODO: Should attempt to do something with the packet

conn.close();

}

}

}+

5

Hey Micah,

I’'m now refactoring some code and will include some recovery logic if an error occured while sending a packet. Will let you know when the enhancement is available.

Thanks,

– Gato

6

You can download tomorrow’'s nightly build which includes new recovery logic. However, you should try fixing the root of your problems which it seems to be a faulty network.

Regards,

– Gato

7

Thanks Gato!

I’'ll test it monday and let you know…