Replies: 2 comments
|
@tttomat19 if you are not sure and wouldn't share any details beyond "too many" allocations, then why did you file this as a bug? |
|
Changing that constant therefore can and will affect the throughput, in particular for the workloads that use multiple channels and high QoS prefetch values. @tttomat19 you are welcome to use a smaller value and report what do the benchmarks look like. Given that this is not a common complaint and the value used is similar to the prefetch value range that's considered to be optimal (going over 300-400 usually produces no throughput improvement), I doubt there will be a lot of interest in tweaking this value. Making it configurable via |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
I can see a lot of allocations from
List<Runnable> block = new ArrayList<Runnable>(size);MAX_RUNNABLE_BLOCK_SIZEis 256 and not configurableCould it be smaller?
To be fair I'm not sure, just JMC shows allocations are right there.
Reproduction steps
about 4k messages per second input * about 1kb size each
Expected behavior
Less wasted allocations from here
Additional context
No response
All reactions