You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Paul Gregoire (JIRA)" <ji...@apache.org> on 2012/12/17 01:56:12 UTC

[jira] [Closed] (DIRMINA-925) Unresponsive I/O once file limit is reached

     [ https://issues.apache.org/jira/browse/DIRMINA-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gregoire closed DIRMINA-925.
---------------------------------

    Resolution: Not A Problem

After considering responses, I can't say this is actually a bug in Mina.
                
> Unresponsive I/O once file limit is reached
> -------------------------------------------
>
>                 Key: DIRMINA-925
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-925
>             Project: MINA
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 2.0.4, 2.0.5, 2.0.7
>         Environment: Linux
>            Reporter: Paul Gregoire
>
> I had this issue reported to the red5 issues list and it reminded me of an issue on an internal company project that uses Mina but has nothing to do with red5 itself. So the common part in these two cases now is Mina, so I am posting this here.
> The gist of both situations is that once the file limit is reached on the os, mina still attempts to do its work but an exception occurs which eventually runs the box of resources.
> What steps will reproduce the problem?
> 1. Use telnet to connect to a servlet's socket until no more connections are allowed (open files limit is reached)
> 2. Use telnet to connect to the tomcat port (5080)
> 3. Observe red5.logs shown below will repeat until the hard drive fills
> java.io.IOException: Too many open files
>         at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~[na:1.6.0_22]
>         at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163) ~[na:1.6.0_22]
>         at org.apache.mina.transport.socket.nio.NioSocketAcceptor.accept(NioSocketAcceptor.java:170) ~[mi
> na-core-2.0.4.jar:na]
>         at org.apache.mina.transport.socket.nio.NioSocketAcceptor.accept(NioSocketAcceptor.java:51) ~[min
> a-core-2.0.4.jar:na]
>         at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.processHandles(AbstractPolling
> IoAcceptor.java:501) ~[mina-core-2.0.4.jar:na]
>         at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.
> java:442) ~[mina-core-2.0.4.jar:na]
>         at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) [mina-core-2.0
> .4.jar:na]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.6.0_22]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.6.0_22]
>         at java.lang.Thread.run(Thread.java:679) [na:1.6.0_22]
> 2012-12-13 15:42:28,521 [NioSocketAcceptor-2] WARN  o.a.m.util.DefaultExceptionMonitor - Unexpected exception.
> Red5 issue #315 - Red5 gets into a tight loop writing error messages if file open limit is exceeded
> https://code.google.com/p/red5/issues/detail?id=315

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira