Openfire

I'm wondering if this is related to the fix of JM-1066. The crux of that issue was moving the MINA idle strategy from BOTH_IDLE to READER_IDLE. The 'both' strategy requires both the reader and writer to be idle. Instead of detecting only reader idle, I think we should detect reader or writer idle.

Looking at the MINA code, this appears to be achievable by setting the idle strategy twice: once for READER_IDLE, and once for WRITER_IDLE (which, combined, is significantly different from BOTH_IDLE).

Wonder if this does the trick:

Index: src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java
===================================================================
--- src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java	(revision 11321)
+++ src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java	(working copy)
@@ -85,6 +85,7 @@
         int idleTime = getMaxIdleTime();
         if (idleTime > 0) {
             session.setIdleTime(IdleStatus.READER_IDLE, idleTime);
+            session.setIdleTime(IdleStatus.WRITER_IDLE, idleTime);
         }
     }

We shouldn't forget to apply any fix to the connectionmanager code too.

Maybe affect version should be 3.6.4 and fix version 3.6.5?

Ah, right. I simply picked the first Jira version that was still open (someone should close it...). I tend to reserve the 'fix version' for those instances where we know in which version the problem was introduced.

User reports catastrophic failure when above patch is applied. All clients that have not been sent any data for the idleTime amount of seconds are disconnected. Instead, we'd like to disconnect only clients that have been sent data which hasn't been delivered to them.

Luckily, MINA also provides setting timeout values on write actions (instead of detecting idle states).

Index: src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java
===================================================================
--- src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java	(revision 11321)
+++ src/java/org/jivesoftware/openfire/nio/ConnectionHandler.java	(working copy)
@@ -85,6 +85,7 @@
         int idleTime = getMaxIdleTime();
         if (idleTime > 0) {
             session.setIdleTime(IdleStatus.READER_IDLE, idleTime);
+            session.setWriteTimeout(idleTime);
         }
     }

The user reporting the initial problem now reports that the cause of his problem is a oversized memory configuration. His JVM was using swap to fill the memory requirement. I've downscaled the impact of this bug.

I'll leave the timeout patch in the code. I recently discovered StalledSessionsFilter which provides similar functionality - it kills idle sessions, based on traffic to-be-sent. My patch uses a timeout, the filter uses an amount of bytes queued to trigger the 'stalled' condition. Both solutions will work nice together.

I would not decrease the priority of this bug. We have been running Openfire for about 2 years now and on the weekend we had huge issues due to someone deciding to connect with the new version of the Empathy client (Ubuntu default). I tried all the possibile memory configuration (from the default one to 1GB of heap space increasing as well the memory of the server to compensate for the increase in Java usage), but nothing helped. As soon as I blocked the IP address of the user connecting via Empathy I could put back the standard 128MB of heap space, but of course it's just a temporary solution.

This is a very critical bug for us and it's probably going to become very critical for more people as soon as users upgrade to the newer Ubuntu.

Matteo, this ticket is not related to Empathy issue. And it is already closed. Check OF-82

Woot,
are you sure that the two issues are not linked? If you read the community discussion linked to this issue http://www.igniterealtime.org/community/message/196900#196900 it seems to affect lots of people after starting to use Empathy. Perhaps the two issues should be merged.

Thanks,
matteo

Although the issues where raised in the the same thread, they are indeed very different issues. Wroot is right: we are tracking the Empathy related issue in OF-82.