Not more than 4 Worker threads

[Umputun]

You actually trying to use Netty as a blocking server, because you eventually blocked event handler. So such behavior (all workers blocked) should be expected. As far as I know, by default Netty uses cores*2 for number of workers (you can change it by adding 3rd parameter to NioServerSocketChannelFactory constructor), so even this magic 4 makes some sense.

If you really want to use Netty in such way, you can just change NioServerSocketChannelFactory to OioServerSocketChannelFactory and probably it will work as you expected (thread per connect). But if you want to work with non-blocking io and small number of threads (for large number of connections) you should not utilize handlers for long time and delegate your heavy processing from messageReceived body to some other executor/pool or something like that. 

regards,
--
Eugene


On Jun 9, 2011, at 1:30 PM, Rajkumar S wrote:

Hello all,

I am testing out netty for a project of mine and started out with the
DiscardServer in the user guide. To simulate a processing delay of 3
seconds and to observe how the system will behave when there is a
processing delay in messageReceived I added a sleep of 3 seconds to
messageReceived in DiscardServerHandler  as shown below:

  public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
       ChannelBuffer buf = (ChannelBuffer) e.getMessage();
       while(buf.readable()) {
           System.out.print((char) buf.readByte());
           System.out.flush();
       }
       try {
               Thread.sleep(3000);
       } catch(Exception ev){}
   }


The client program is a simple perl program that connects to the
server and transmit one line of text. This perl program is started 100
times by a loop in in a shell script to simulate 100 concurrent
connection.

I was expecting the DiscardServer to launch 100 worker threads where
each will print all the incoming message in one step and then sleep
for 3 seconds.

What I observed was that 4 messages are printed, then wait for 3
seconds, again 4 messages and 3 seconds wait till all the messages are
printed. During this time can see the connections that are not
processed in netstat.  They are are in CLOSE_WAIT and Recv-Q  has a
size of 6 (which is the number of characters in the line of text sent
by client) During every 3 seconds 4 connections will disappear from
netstat output as they are processed by DiscardServer. An example line
from netstart is as follows:

tcp6       6      0 192.168.3.18:8080       192.168.3.18:41671      CLOSE_WAIT

Now my questions are:

1. Is this the expected behavior?
2. Why didn't the number of threads increase to process the
connections that were available?
3. Why the magic number of 4? (I am using a Core2 Duo CPU with 2
cores) I tried to use newFixedThreadPool but the number of threads
started does not go above 4, but it does come down if a number < 4 is
used.
4. In a real world application if there is a heavy processing involved
for received messages (say takes three seconds to process each
message) is the correct approach to add that to messageReceived
method?
5. Am i missing any thing here? :)

I am just trying to get a hang of the natty library and event driven
programming in general. So please excuse me asking so many trivial
questions!

Thanks and regards,

raj
_______________________________________________
netty-users mailing list
netty-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/netty-users