Server stops communicating using ''old style ssl''

Openfire Openfire Dev
1

The server sometimes stops communicating over 5223. People cannot login or logout any more. A (temporary) workaround is by first disabling ‘‘old style ssl’’ in the webadmin (security settings), then enabling it again.

Does anyone know what might be causing this?

2

Hi Guus,

which version are you using, if it’'s 3.2.0 then you may want to update as JM-970 was fixed in 3.2.1 and as far as I know introduced in 3.2.0.

LG

3

Sorry, I should have mentioned we were using 3.2.2.

4

Hi Guus,

maybe Gato has already an idea, but it may help to have a javacore (kill -3 wildfirepid) and some more information. Is the SSL socket still open and one get’'s a timeout?

LG

5

I’'ve attached the thread-dump that we took when we had the problem.
full-tread-dump.txt (93133 Bytes)

6

It seems that a lot of threads are waiting for the operation NIOConnection.deliverRawText(NIOConnection.java:239) to finish. This method is called as part of the mechanism that closes idle sessions:

- locked <0x00002aaaf68827f0> (a org.jivesoftware.wildfire.nio.NIOConnection)
     at org.jivesoftware.wildfire.nio.ConnectionHandler.sessionIdle(ConnectionHandler.java:96)

I wonder if this problem is related to JM-993

7

deliverRawText uses this code to write </stream:stream> after a connection has been idle:

ioSession.write(buffer).join();

The write method called on the ioSession object returns an IoFuture instance. This ‘‘future’’ can be used to track the asynchronous results of operations called on the original object. The “join” method that’'s being called on the ‘‘future’’ object waits for the asynchronous operation to end.

Waiting for an asynchronous operation to end on an object that is know to be in a non-expected state (’‘idle’’ while it should have sent whitespaces) can be considered tricky. The IoFuture class has an overloaded join method, that takes a timeout. Can we use that instead of the -wait-forever- method that’'s used now?

Message was edited by: Guus

I just realized that this is probably causing JM-993 as well: An attempt to </stream:stream> locks forever before the session is closed - causing the session not to be closed.

8

Hi Guus,

I just took a look at the thread dump. It seems that the number of nio threads is limited and as soon as all threads are locked as you posted above one get’'s this problem. Is this really the case / can you reproduce this issue using one client to login and logoff 40 times?

LG

9

I’'m pretty sure that JM-993 covers this case, which was fixed for the 3.2.3 release. Gato is continuing to do some tweaking to the Mina layer, though.

Regards,

Matt