4

Please give me advice how to increase my ByteBuf initial capacity.
In situation like:

 @Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception { byte[] byteinput = new byte[in.readableBytes()]; in.readBytes(byteinput); //further handling... }

If income message more than max capacity of ByteBuf - i get cutted data. Its vital for this project to get whole, non chunked message.

I suppose i need to set initial capacity of ByteBuf somewhere in bootstraps childOptions, or in cannel.config()... inside of ChannelInitializer.
And i tried different ways like setting

ch.config().setReceiveBufferSize(1024)

but i still have same value of ByteBuf capacity(e.g. 496).

UPD

I discovered my protocol traffic with wireshark, and packets up to 1,4k going uncorrupted out and in from my test user client. This issue is only matter of netty settings. Operating system socket buffer do not cuts messages.

Improve this question
2
  • The 'receive buffer size' is the size of the socket receive buffer in the kernel. Nothing to do with Netty, NIO, or Java. Commented Oct 31, 2014 at 4:49
  • Thats true. But for my current machine, input socket buffer is at least 8k. My message cuts at 498 bytes. And when i look into ByteBuf instance fields i see "(max) capacity = 498". I need to find where is factory or initial settings of this ByneBuf and change it initial capacity. Im not trying to send 1MB in one chunk, i need only 1k Commented Oct 31, 2014 at 8:45

3 Answers 3

Reset to default
6

That was easy as pie. 

ServerBootstrap b = new ServerBootstrap(); // (2) b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) // (3) .childHandler(new ChannelInitializer<SocketChannel>() { // (4) @Override public void initChannel(SocketChannel ch) throws Exception { //decrypt //checknum ch.config().setRecvByteBufAllocator(new FixedRecvByteBufAllocator(2048)); //set buf size here ch.pipeline().addLast(new InboundDecryptor()); . . .
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

You may be able to configure Netty's buffer allocation sizes but there are likely more general limitations you are subject to. Netty is an asynchronous framework. This means it will read what ever is made available to it by the OS and pass that on to you. Netty has no control over network conditions, networking hardware behavior, OS behavior, or anything else in between your producer of data and your Netty application. If your application logic requires complete application level messages you may have to aggregate the data before you invoke this application logic. Netty has some convenience methods to help with this see MessageAggregator.java and for an HTTP specific implementation see HttpObjectAggregator.java.

Improve this answer

4 Comments

Intresting links. </br> My app will receive packets that less than max tcp packet size(1400 bytes) but more than 400bytes. So i suppose my message will come not chunked. I just need to increase income ByteBuf size
Your "suppose" terminology indicates you are not sure? It may be helpful to others if you provide some more details and references as to how you know your message will not be chunked. Describing your environment may also be relevant (for example is this going over the general internet or is it in a controlled environment, are your clients/servers only supported on a particular set of OSs).
I understand that now I can not test all possible configurations of the system and i need keep in mind possible problems. Thats why i said "suppose", to not assert it categorically, as I might do not know about the some pitfalls. I looked into wireshark (program for precise monitoring of network) listings to check any TCP packets to my server port. Server and client are connected via outer network. So wireshark showed, that big packet (1,4 kB) came as whole. For systems Windows Seven x64 and Android 3+; I started to experiment with parameters in different parts of server/channel initializers.
I'm not suggesting testing all possible configurations. Just understand the environment you are operating in. Then you can test the minimal amount of configurations that have meaningful differences. I don't know your entire architecture (or environment) but as long as you understand the general problem I am describing then you should have enough information to make an informed decision.
0

Scott is right. Increasing only the size of buffer does not solve the problem. 

ch.config().setRecvByteBufAllocator(new FixedRecvByteBufAllocator(2048));

For HTTP requests it also should use HTTPObjectAggregator. It worked for me.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.