Reputation: 3605
Netty best practices (slides w/ video) by Norman Maurer introduces the WRITE_BUFFER_HIGH_WATER_MARK
and WRITE_BUFFER_LOW_WATER_MARK
option. It also gives and example:
//Server
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.childOption(ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK, 32 * 1024);
bootstrap.childOption(ChannelOption.WRITE_BUFFER_LOW_WATER_MARK, 8 * 1024);
//Client
Bootstrap bootstrap = new Bootstrap();
bootstrap.option(ChannelOption.WRITE_BUFFER_HIGH_WATER_MARK, 32 * 1024);
bootstrap.option(ChannelOption.WRITE_BUFFER_LOW_WATER_MARK, 8 * 1024);
There is also another discussion on this topic on StackOverflow. But I'm still not sure about some details.
Do the high and low write watermarks options set in client side control the behaviour of the queue written from client to server, and the server side options control the behaviour of the queue written from server to client?
Which means if the server side high watermarks options is set, then the server side channel which writes data to client becomes not writable when the client receives slowly and the previously written data has filled the queue? And vice versa for client side options.
BTW, I'm using netty 4.1.0CR.
Upvotes: 1
Views: 435
Reputation: 8257
Which means if the server side high watermarks options is set, then the server side channel which writes data to client becomes not writable when the client receives slowly and the previously written data has filled the queue? And vice versa for client side options.
Once the data in the channel reaches high watermark the channel.isWritable method starts returning false until the channel reaches low watermark again.
But then, if we don't check/ignore channel.isWritable status and keep writing to channel even after it reaches high watermark, it could ultimately result in OOM error as indicated in the two previous slides.
UPDATE
Do the high and low write watermarks options set in client side control the behaviour of the queue written from client to server, and the server side options control the behaviour of the queue written from server to client?
That is absolutely true.
Upvotes: 2