You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Erick Lichtas <EL...@linoma.com> on 2014/09/25 22:00:41 UTC
NIOProcessor thread causes 100% cpu usage in certain scenario
Hi everyone,
I have ran into a situation with Mina that causes the NIOProcessor threads to run away and consume all available CPU on the system (of the current core to be more accurate). My context is that I'm running the Apache FTP server, but instead of using the bundled version of Mina 2.0.4, I am running it on 2.0.7. This works great for the most part.
My situation occurs when the security provider (JSafeJSSE) I'm using rejects the SSL handshake because the FTPS client doesn't have any strong enough supported ciphers (stacktrace included below), this causes the NIOProcessor thread of MINA to get stuck. I've tracked it down to the following block of code in the AbstractIoBuffer.shrink() method:
for (;;) {
if (newCapacity >>> 1 < minCapacity) {
break;
}
newCapacity >>>= 1;
}
Ultimately in my situation, newCapacity becomes 0 and minCapacity becomes 0 and the loop never ends. I assume this should never happen, but in my scenario with the FTP server, it does. Do any of the MINA developers and/or users have any insight they can provide and recommendations to fix?
I've tested throwing an IllegalStateException if minCapacity == 0, and that seems to protect the thread from getting stuck in this loop, however I'd like some input from the dev team. I can open a JIRA case if you agree there is a problem here, but I'm more interested in implementing some workaround which I would be happy to test out.
This does not occur in MINA 2.0.4, but is reproducible in 2.0.6, 2.0.7, and 2.0.8 (I'm unable to start the FTP server on 2.0.5 as there appears to be some missing code in MINA).
Thanks in advance!!!
Regards,
Erick
PS, here is the promised stacktrace:
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
at org.apache.mina.filter.ssl.SslFilter.messageReceived(Unknown Source)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(Unknown Source)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(Unknown Source)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(Unknown Source)
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(Unknown Source)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(Unknown Source)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(Unknown Source)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(Unknown Source)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(Unknown Source)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(Unknown Source)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(Unknown Source)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLException: No shared ciphers for protocol
at com.rsa.sslj.x.aG.b(Unknown Source)
at com.rsa.sslj.x.aG.a(Unknown Source)
at com.rsa.sslj.x.aG.b(Unknown Source)
at com.rsa.sslj.x.aI.wrap(Unknown Source)
at org.apache.mina.filter.ssl.SslHandler.handshake(Unknown Source)
at org.apache.mina.filter.ssl.SslHandler.messageReceived(Unknown Source)
... 16 more
Caused by: com.rsa.sslj.x.aJ: No shared ciphers for protocol
at com.rsa.sslj.x.bG.j(Unknown Source)
at com.rsa.sslj.x.bG$1.run(Unknown Source)
at com.rsa.sslj.x.aG$1$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.rsa.sslj.x.aG$1.run(Unknown Source)
at org.apache.mina.filter.ssl.SslHandler.doTasks(Unknown Source)
... 18 more
RE: NIOProcessor thread causes 100% cpu usage in certain scenario
Posted by Erick Lichtas <EL...@linoma.com>.
Hi Emmanuel,
This is fantastic and thank you! I have applied your change locally and have ran some tests and things seem to be working as expected now. I will continue to test it out and let you know if I encounter any other problems related to this.
Thanks again,
Erick
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Friday, September 26, 2014 5:16 AM
To: dev@mina.apache.org
Subject: Re: NIOProcessor thread causes 100% cpu usage in certain scenario
Le 25/09/14 22:00, Erick Lichtas a écrit :
> Hi everyone,
Hi,
I created the JIRA : https://issues.apache.org/jira/browse/DIRMINA-988
and applied a fix on it.
It should be released soon.
Re: NIOProcessor thread causes 100% cpu usage in certain scenario
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 25/09/14 22:00, Erick Lichtas a écrit :
> Hi everyone,
Hi,
I created the JIRA : https://issues.apache.org/jira/browse/DIRMINA-988
and applied a fix on it.
It should be released soon.
Re: NIOProcessor thread causes 100% cpu usage in certain scenario
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 25/09/14 22:00, Erick Lichtas a écrit :
> Hi everyone,
Hi Erick,
>
> I have ran into a situation with Mina that causes the NIOProcessor threads to run away and consume all available CPU on the system (of the current core to be more accurate). My context is that I'm running the Apache FTP server, but instead of using the bundled version of Mina 2.0.4, I am running it on 2.0.7. This works great for the most part.
>
> My situation occurs when the security provider (JSafeJSSE) I'm using rejects the SSL handshake because the FTPS client doesn't have any strong enough supported ciphers (stacktrace included below), this causes the NIOProcessor thread of MINA to get stuck. I've tracked it down to the following block of code in the AbstractIoBuffer.shrink() method:
>
> for (;;) {
> if (newCapacity >>> 1 < minCapacity) {
> break;
> }
> newCapacity >>>= 1;
> }
Ugly...
i'll fix that asap.
Can you fill a JIR ?
Many thanks !