gemmellr commented on pull request #3812: URL: https://github.com/apache/activemq-artemis/pull/3812#issuecomment-950990954
I would probably make them mutually exclusive personally, as they will most likely never agree exactly on when to block and unblock so it seems odd to set both. Although that could be awkward since max-disk-usage has a built in default, so its currently 'almost always set' in a way, and your PR currently proposes having a default for the 'min available' too. If you allow them both to be configured then it really has to start blocking when either is breached, or else one of them simply wouldn't be doing what was asked. It would have to ensure both are not breached before unblocking though, or again it wouldnt be doing what one of them asked. Since the existing functionality uses 'max-disk-usage' as a name, I think something like 'min-disk-...' would be more consistent than 'min-free-disk-bytes' is. I wouldn't put the 'bytes' units in the name, allowing for more friendly unit-specifying strings to also be supplied, e.g. as is supported for the "global-max-size". If allowing for units, a different route and obvious simplification to avoid needing to consider any conflicting 'max usage' and 'min available' configurations would be to instead just extend what the existing 'max-disk-usage' can do and allow it to specify the actual usage amount rather than a percentage of the total. Values without units (or even just values <=100) could retain the existing behaviour as a percentage of total, whilst enabling configuration strings with units to pass a literal size for the actual disk usage amount. (That could still be done even if adding 'min available' functionality, but returns us to the question of whether to allow both to be set and what to do with them) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
