Hey Ryan,
Yes, your change fixes the issue. So is that way i'm configuring the selector thread pool in error? Will selector threads even idle timeout if code/min sizes are not the same?
Thanks for looking into this!
-paul
From: Ryan Lubke <ryan.lubke_at_oracle.com<mailto:ryan.lubke_at_oracle.com>>
Reply-To: "users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>" <users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>>
Date: Friday, January 17, 2014 6:07 PM
To: "users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>" <users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>>
Subject: Re: EOFException
Hi Paul,
Can you make the following minor changes outlined here [1] and see if it resolves your issue?
Thanks,
-rl
[1]
https://gist.github.com/rlubke/8483356
Sprague, Paul wrote:
Yes. The listen socket is still accepting connections though (I can telnet into it).
When I SSH into the port it just hangs though:
ssh -vvv -p10121 localhost
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 10121.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/paul/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/paul/.ssh/id_rsa type 1
debug1: identity file /Users/paul/.ssh/id_rsa-cert type -1
debug1: identity file /Users/paul/.ssh/id_dsa type -1
debug1: identity file /Users/paul/.ssh/id_dsa-cert type -1
^C
Reduced server setup code here:
http://pastebin.com/MaS6imAA
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com<mailto:oleksiy.stashok_at_oracle.com>>
Reply-To: "users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>" <users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>>
Date: Thursday, January 16, 2014 2:01 AM
To: "users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>" <users_at_grizzly.java.net<mailto:users_at_grizzly.java.net>>
Subject: Re: EOFException
Hi Paul,
On 15.01.14 12:09, Sprague, Paul wrote:
I've encountered this java.io.EOFException in 2.3.10 on a TCP/TLS server I've written. This happens after the client performs a transport.shutdownNow(). Once this happen the grizzly server is dead in the water.
what do you mean? It stops accepting and respond to new connections?
WBR,
Alexey.
20140115-14:42:31.762-0500|worker(4)|DEBUG|org.glassfish.grizzly.nio.transport.TCPNIOTransport|TCPNIOConnection (TCPNIOConnection{localSocketAddress={/127.0.0.1:10121}, peerSocketAddress={/127.0.0.1:51253}}) (plain) write 74 bytes
20140115-14:42:32.506-0500|worker(5)|DEBUG|org.glassfish.grizzly.nio.transport.TCPNIOTransport|TCPNIOConnection (TCPNIOConnection{localSocketAddress={/127.0.0.1:10121}, peerSocketAddress={/127.0.0.1:51253}}) (nonallocated) read -1 bytes
20140115-14:42:32.513-0500|worker(5)|DEBUG|org.glassfish.grizzly.filterchain.DefaultFilterChain|Exception during FilterChain execution
java.io.EOFException: null
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.read(TCPNIOTransport.java:699) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:75) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.ssl.SSLBaseFilter$SSLTransportFilterWrapper.handleRead(SSLBaseFilter.java:977) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:290) [grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:208) [grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136) [grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114) [grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:545) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) ~[grizzly-framework-2.3.10.jar:2.3.10]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) ~[grizzly-framework-2.3.10.jar:2.3.10]
at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
Let me know what additional information might help.
Thanks,
Paul