Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.
I've found the below stacktrace (for the first time) in my app logs before it got crashed by an OOM. Version used is 2.3.25.
Is this a known issue? Please let me know if you need any information.
Oct 28, 2017 5:59:32 AM org.glassfish.grizzly.filterchain.DefaultFilterChain execute
WARNING: GRIZZLY0013: Exception during FilterChain execution
java.lang.IllegalStateException: Unknown protocol SIP/2.0
at org.glassfish.grizzly.http.Protocol.valueOf(Protocol.java:111)
at org.glassfish.grizzly.http.HttpHeader.getProtocol(HttpHeader.java:815)
at org.glassfish.grizzly.http.HttpServerFilter.prepareResponse(HttpServerFilter.java:867)
at org.glassfish.grizzly.http.HttpServerFilter.encodeHttpPacket(HttpServerFilter.java:834)
at org.glassfish.grizzly.http.HttpServerFilter.commitAndCloseAsError(HttpServerFilter.java:1185)
at org.glassfish.grizzly.http.HttpServerFilter.sendBadRequestResponse(HttpServerFilter.java:1177)
at org.glassfish.grizzly.http.HttpServerFilter.onHttpHeaderError(HttpServerFilter.java:796)
at org.glassfish.grizzly.http.HttpCodecFilter.handleRead(HttpCodecFilter.java:583)
at org.glassfish.grizzly.http.HttpServerFilter.handleRead(HttpServerFilter.java:334)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:526)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.base/java.lang.Thread.run(Thread.java:844)
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f9e403f4000, 65536, 1) failed; error='Not enough space' (errno=12)
I've found the below stacktrace (for the first time) in my app logs before it got crashed by an OOM. Version used is 2.3.25.
Is this a known issue? Please let me know if you need any information.