Sprague, Paul wrote:
> Hey Ryan,
>
> Yes, your change fixes the issue. So is that way i'm configuring the
> selector thread pool in error?
I think we need to be smarter about this on our side. I'll be looking
into fix that so these kind of surprises don't happen.
> Will selector threads even idle timeout if code/min sizes are not the
> same?
Did you mean core/max? If so, it shouldn't have an impact.
> 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
>>