[JAVA-108] ByteEncoder and ByteDecoder allocate 8+M buffer each Created: 21/Apr/10  Updated: 29/Oct/10  Resolved: 18/May/10

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: 1.4
Fix Version/s: 2.0

Type: Improvement Priority: Major - P3
Reporter: Ben Smith Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

osx, linux



 Description   

ByteEncoder and ByteDecoder allocate 8+M buffer each which means 16+M for each connection.

This means we need to increase the MaxDirectMemorySize quite significantly to be able to create a decent number of connections to perform well under many concurrent requests.

While I can understand why this has been done, it would be good to be able to at least configure the MAX_OBJECT_SIZE for our application, as we'll only ever be passing around documents < 1M.

Alternatively, could the encoder and decoder stream the requests using a much smaller buffer.

Am happy to look at creating a patch depending upon preferred solution.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 18/May/10 ]

no more large allocations

Comment by Ben Smith [ 22/Apr/10 ]

Yeah, I may be wrong about that, but that's the behaviour we were seeing. I'll see about recreating the test harness.

Comment by Eliot Horowitz (Inactive) [ 21/Apr/10 ]

Why do you think they are 8M each? should be 4M each for a total of 8.

We could make the Encoder smarter, but the decoder should stay as is.
Its shown to be much better for most apps this way, as the java driver is definitely a bit enterprise focused.

We could make it use about 5M / connection pretty easily if that would help, but lets first confirm if its 8 or 16 per pair.

Generated at Thu Feb 08 08:51:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.