New to netty

[manish_iitg]

Hello,

Thanks for the explanation. I really helped.

Also, while using blockingqueue is found that, if we place the call to
BlockingQueue.take() in the channelConnect method of the handler. Then it
doesnt work. What happens is, no futhur call to message recieved, or any
other method takes place. But by placing the BlockingQueue.take() call,
where you connect you client to the server, the request becomes synchronous. 

Thanks




Frederic Bregier wrote:
> 
> Hi Manish,
> 
> In Netty, you have two kinds of thread pools.
> 1) The first one is attached to the channel handling itself. It is created
> using
> the NioClientSocketChannelFactory to pass to the ClientBootStrap.
> You specify two Executor, one for the low level channel handling
> (connection
> for instance), and one for the upper level handling (receive or sending
> messages).
> The two executor must be (or should be) created using
> Executors.newCachedThreadPool().
> You can add a spcific number that specifies the number of maximum active
> threads
> at a time (should be close to the number of real processors or so).
> 
> 2) The second is to be added into the ChannelPipeline using 
> pipeline.addLast("executor", new ExecutionHandler(new
> OrderedMemoryAwareThreadPoolExecutor(16, 0, 0));
> This thread pool is to be placed in the pipeline before the business
> ChannelHandler.
> It is intend to enable long term or blocking business action (like access
> to a
> database, or long computation like MD5, file writing, ...).
> The necessity of such a thread pool depends on the business work.
> For instance, if the server or client does nothing except answering to the
> request
> by a very simple message without much computations, then it is not
> necessary.
> But if the server  or client does much computation or can be blocking,
> then you have to insert such a thread pool.
> Take a look at the API of Netty: 
> 
> http://www.jboss.org/file-access/default/members/netty/freezone/api/3.1/org/jboss/netty/channel/ChannelPipeline.html
> 
> Also this kind of Thread Pools are Memory Aware so that you can specify
> some limits to prevents out of memory during execution (see tha API again
> how).
> 
> Between the MemoryAware and the OrderedMemoryAware thread pool, I would
> say
> that for most usage, you should use OrderedMemoryAware since it ensures
> the
> order of message for the business handler.
> Some protocols do not need such an order, so they can use the other one,
> simpler.
> 
> Now on your example, 
> - For the server, if it does some complex computations (or blocking
> actions),
> then add the OrderedMemoryAwareTPool to the pipeline. I would say it is
> always
> a good idea.
> - For the client, it really depends on the protocol. If your client sends
> only
> one message and quit after receiving the answer (which it seems according
> to
> your description but I can have miss something), then you don't have to
> take
> care to add a ThreadPool to your pipeline (the client has only the server
> as
> partner, as opposite to the server which could have a lot of
> partners-clients).
> You can even just forget the NioClientSocketChannelFactory when creating
> the ClientBootStrap (Netty will create a simple one for you).
> 
> As Netty uses some threads (from ClientBootStrap) to handle connection and
> sending and receiviong messages, the class where you create your
> ClientBootStrap
> will run in a separate thread than the Netty Class, so that you can simply
> wait for the blockingqueue to release the main Class (or whatever option
> you use to block the main class before to continue the job).
> 
> Also another option is to add into your SimpleChannelHandler in the
> messageReceived() method your business job if you have to continue to
> send messages. The solution I present to you is essentially valid if
> the connection can be considered as over (to be closed or already closed).
> If the connection must be used again, then  it is in the messageReceived()
> that you will implement the continuation of your business, or a mix
> between
> the two solutions...
> 
> Of course, if Trustin sees something wrong in what I wrote,
> he will check it and correct it ;-)
> 
> HTH,
> Frederic
> 
> 

-- 
View this message in context: http://n2.nabble.com/New-to-netty-tp1625621p1648032.html
Sent from the Netty User Group mailing list archive at Nabble.com.