Using Netty

Trustin Lee tlee at redhat.com
Thu May 14 23:00:07 EDT 2009


On Wed, May 13, 2009 at 2:30 PM, Christian Migowski
<chrismfwrd at gmail.com> wrote:
> Hi Rajks,
>
> just some random pointers from another Netty user:
>
> On Wed, May 13, 2009 at 2:46 AM, rajks <rajks at hotmail.com> wrote:
>>
>> Should I implement the DB server also as Netty NIO HTTP based and use the
>> Netty NIO HTTP client as means to communicate between front end servers and
>> db servers. NOTE: each front end server will be communicating with many
>> back-end DB servers. We would like to have PERSISTENT connections with some
>> limit per host;
>
> If I don't have to, I wouldn't use http as communication protocol.
> IIRC http had originally non-persistent connections only (I am not
> familiar with Nettys http implementation), also it has probably more
> features (which means more overhead) then you need for your servers
> talking to each other.
> IMHO designing a simple protocol (with a small header like
> <msglength><actioncode><msgId> ) for your own use would be better
> (less complex in case of problems, propably more efficient)
>
>> Which approach is scalable and have performance benefits with Netty or is
>> there a better way to exploit Netty. Can I use the Netty client in teh front
>> end server to distribute the requests to back-end DB server on a set of
>> persistent connections.
>
> As far as I know, Netty has no proxy functionality available.

However, it is definitely possible to implement a HTTP proxy server
with Netty, and I know a couple users who successfully did it.

>> Does Netty handle by default uploading of big files by N number of
>> concurrent sessions or do we need to do something in the server side after
>> each MessageReceived event to say suspend read so that IO does not read
>> until the every chunk is written to the disk. after this resume read again.
>> Does suspend and resume reads affect performance;
>
> Again as far as I know Netty has no write to disk/somewhere else
> related things included. If you expect big files you'd better not
> buffer them in memory until complete (you may run out of it).

I think Rajks asked a different question.  Suspend/resume operation
affects performance somewhat, but it will depend on various factors -
you need to test by yourself in this case.

>> Also is this taken care of automatically by using the
>> OrderedMemoryAwareExcecutor as I see some topics in this forum recommending
>> to use the OrderedMemoryAwareExcecutor to handle the memory issue and as
>> well for high latency back-end operations.

Yes.  A read operation will be suspended and resumed automatically
depending on the size of the task queue in the executor.

So, I believe Netty is suitable for your use case IMHO.

HTH,

— Trustin Lee, http://gleamynode.net/




More information about the netty-users mailing list