ClosedChannelException with concurrent connections - what am I doing wrong?

[Johnny Luong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nate Murray wrote:
| Okay, it looks like somehow I am writing to a closed channel. However, I
| don't see how this could be.
|
| As is probably obvious by now, I'm a Netty newbie and I'm trying to figure
| out if I should use Netty vs. going with erlang or a c-based server. I
hear
| a lot of good things about Netty, I think I just need to understand better
| how it works.
|
| I'm trying to build a simple but fast HTTP/REST server. I don't need tcp
| keepalive or any sort of streaming to be supported.
|
| A couple thoughts:
|
|   * Maybe my OrderedMemoryAwareThreadPoolExecutor is asking for too many
| threads? Is 1000 too high?
|   * Do I get any benefit from setting my "backlog" option higher? What's a
| reasonable value?
|   * Should I reuseAddress?
|
| And this is my biggest question:
|
|   * Why do I receive a valid Channel in messageReceived but that
Channel is
| closed by the time I write to it in writeResponse?
|
| I get about ~100 concurrent connections with the code above just fine.
Am I
| expecting too much of Netty asking for 500?
|
| Setup:
| Mac OS X, -Xmx2g, Netty 4.0.0.Alpha1-SNAPSHOT
|
| Thanks,
|
| Nate

Hi Nate,

My two cents:

I would probably drop the OrderedMemoryAwareThreadPoolExecutor since you
are using a cached thread pool as your worker thread unless your
profiler shows a significant amount of time is spent within your handler.

Changing the default backlog option will help you if the accept loop is
not processing fast enough.  If your getting connection refused from the
client perspective, then this is something you may want to increase to
decrease the possibility of a connection refused.

The reuseaddress shouldn't really change the performance aspect of your
application.  I've generally enabled in the application I write using
Netty though mainly because I don't want to wait for all the TCP
connections in a TIME_WAIT state to go away before restarting the
application.

I'm not really sure what your looking for so it's tough to say if your
expectation is reasonable or not.  I ran a slightly modified example
(removed the executor above and used the siege benchmark tool instead)
and got the following numbers on a desktop linux box:

johnny at spike:~$ siege --concurrent=500 -b http://127.0.0.1:3335/
Transactions:		      346547 hits
Availability:		       99.92 %
Elapsed time:		      112.73 secs
Data transferred:	        2.97 MB
Response time:		        0.14 secs
Transaction rate:	     3074.13 trans/sec
Throughput:		        0.03 MB/sec
Concurrency:		      416.55
Successful transactions:      346547
Failed transactions:	         278
Longest transaction:	       46.80
Shortest transaction:	        0.00

I didn't see any exceptions thrown so I think increasing the server
backlog would help in the previous run.  I think the numbers that are
more useful is the response time, longest transaction, and transaction
rate though rather than a focus on how many accepts were processed which
leads to the following run:

johnny at spike:~$ siege --concurrent=20 -b http://127.0.0.1:3335/
Transactions:		      204733 hits
Availability:		      100.00 %
Elapsed time:		       62.33 secs
Data transferred:	        1.76 MB
Response time:		        0.01 secs
Transaction rate:	     3284.66 trans/sec
Throughput:		        0.03 MB/sec
Concurrency:		       18.75
Successful transactions:      204733
Failed transactions:	           0
Longest transaction:	        0.17
Shortest transaction:	        0.00

Hope this helps,
Johnny

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkxjE6cACgkQg7TIS7A9isd8ngCfeR4JekAzMJOT/1TFWprygYUV
sZQAnj3JV36gTiJviUGLhWfu86uWverK
=P58V
-----END PGP SIGNATURE-----