Project

General

Profile

Infinite loop detected in writeBuff(buff) TLS code, tlsWrapper.getStatus(): NEED_READ

Matthew M
Added almost 5 years ago

We see this quite often, with tigase server 5.2.1 final version.

Infinite loop detected in writeBuff(buff) TLS code, tlsWrapper.getStatus(): NEED_READ

We are using both BOSH and TCP connection from clients, and seems more often with BOSH (however we have more BOSH users than TCP users).

Is there anything we should do? I saw this post: https://projects.tigase.org/boards/4/topics/67

Andrzej Wójcik wrote:

If I remember correctly we solved this issue by adding additional configuration paramter to Tigase XMPP Server.

If you would like to still use Java 7, you should add line containing --tls-jdk-nss-bug-workaround-active=true to etc/init.properties file, a workaround for using new TLS/SSL implementation in Java 7 and not fully compatible SSL/TLS libraries on client side would be activated then.

In fact we saw this both with Java 6 (with any early version of tigase) and Java 7 (with latest tigase release). Is this what we should do, or is there anything other solution?

Thanks!


Replies (5)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

Do you use OpenJDK or Oracle's (Sun's) JDK?

Added by Matthew M almost 5 years ago

We use OpenJDK 1.7

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

This is what I thought. The bug in the networking IO in JVM which causes this infinite loop has been fixed in JDK7 but only in Sun's (Oracle) version of the JDK. As far as I know it was not fixed in the OpenJDK. Please try the version from Oracle and let us know if this works for you.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

By the way, this JVM bug is more or less correctly handled by Tigase in that sense that it does not impact performance or other connections. Well, the bug itself has some slight performance impact as it consumes some resources before it is detected by Tigase like a higher CPU for a few milliseconds.

What really happens is that a TCP/IP connections is closed but the connection state is incorrectly detected by JVM and it reports that the connection is ready to read some data from. Tigase tries to read data, but none is in there, so it puts the connection back to the reading selector. Then JVM again reports it as it has some data ready to read and this goes on and on in an infinite loop.

So the Tigase detects this and just removes such a connection from the pool. Therefore, this is not something you should be concerned about.

Added by Matthew M almost 5 years ago

Many thanks for the explanation! So it seems there is no harm for this warning and we can ignore it...

    (1-5/5)