Client optimizations.

[Yury-Fridlyand]

JNI netty client optimizations:

1. Remove unused code
2. Optimize responses future array
3. Delete completed futures, but array isn't squashed
4. Speed up async functions - they return a future faster now; overall performance is slightly reduced though
   Long operation - building the command with protobuf - moved to async code.
5. Make callbackId unique to allow concurrent clients (avoid conflict with commands with the same callback id)
6. Modify building a protobuf structs to make it faster

Performance measurements for protobuf structs

Test	Routes - set fields	Routes - build	ArgsArray - addAllArgs - set fields	ArgsArray - addAllArgs - build	ArgsArray - loop addArgs - set fields	ArgsArray - loop addArgs - build	Command
SET	983781	660142	7095307	578097	3247998	250048	598259
GET NE	690858	548569	3640514	466618	905769	154742	491210
GET E	739133	558772	3219779	358226	664723	164943	515029

[jduo]

It would be worth setting up the checkstyle plugin to group together packages (eg everything in org in one group), alphabetize, etc.

[Yury-Fridlyand]

We have spotless in the project, it should do all work. Code clean up is planned, thank you.

[jduo]

Generally prefer to avoid * imports to avoid over-importing.

[Yury-Fridlyand]

spotless should fix this as well.

[jduo]

I don't think this is guaranteed to be a unique offset?

1. Every instance is getting its own Random() object instead of sharing a generator.
2. I don't know if it's guaranteed that a Random can't generate the same number multiple times?

Could use a static AtomicInteger counter. It'd be unique but predictable.

[jduo]

Design question -- are we creating several JniNettyClients and funneling a single or small number of task through each one, or creating a limited number of JniNettyClients and funneling a large number of tasks through them?

Netty (and async I/O in general) is more efficient for the latter case. It better handles resources than creating a bunch of threads and having one socket per thread.

[Yury-Fridlyand]

Offset handling will be changed in https:/orgs/Bit-Quill/projects/4/views/6?pane=issue&itemId=44643871
We also planned to optimize Netty resource usage in https:/orgs/Bit-Quill/projects/4/views/6?pane=issue&itemId=44643464

[jduo]

The inability to parse a protobuf object directly from a ByteBuf is annoying. There are some solutions here you could use to avoid having to allocate the byte array, copy into, then throw it away:
https://stackoverflow.com/questions/29690118/how-to-parse-google-protocol-buffers-that-in-the-direct-memory-without-allocatin

[jduo]

Actually, maybe you can use Netty's built-in Protobuf encoder/decoder instead of dealing with message serialization yourself:
https://netty.io/4.0/api/io/netty/handler/codec/protobuf/ProtobufDecoder.html
Then you don't need to mess around with ByteBufs or byte arrays.

[Yury-Fridlyand]

It is already used in lines 158-159