[GLASSFISH-20340] [regression] Make HK2 cache io buffer size is not configurable Created: 17/Apr/13  Updated: 20/Dec/16  Resolved: 18/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_dev
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: mtaube
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, performance


It used to be configurable earlier, but during hk2 2.x, it has been changed to become a fixed value. Fix it so that perf team can use it to tune the system.

Comment by mtaube [ 18/Apr/13 ]

What is the impact on the customer of the bug?

They will see a performance improvement during startup when io buffer size is optimized for the machine running glassfish

What is the cost/risk of fixing the bug?

This particular change is not risky, will only take effect if a property is specified in osgi.properties

Is there an impact on documentation or message strings?


Which tests should QA (re)run to verify the fix did not destabilize GlassFish?


Which is the targeted build of 4.0 for this fix?


If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.


Comment by Tom Mueller [ 18/Apr/13 ]

I hesitate in approving this in that I don't completely agree that this should even be tunable (or should have ever been tunable). More knobs are not necessarily better, and there isn't any proof that different values are needed for different systems. And even if different values were beneficial, is there actually going to be documentation on how users could actually tune this value or is there a performance tuner that sets the value. IMHO, it would be better to just determine a single value that is reasonable for the systems that we target and put that value in the code.

Approved for 4.0.

Generated at Wed Mar 29 16:13:05 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.