You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Thomas Mueller (JIRA)" <ji...@apache.org> on 2019/07/31 09:58:00 UTC
[jira] [Created] (OAK-8523) Best Practices - Property Value Length
Limit
Thomas Mueller created OAK-8523:
-----------------------------------
Summary: Best Practices - Property Value Length Limit
Key: OAK-8523
URL: https://issues.apache.org/jira/browse/OAK-8523
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, jcr
Reporter: Thomas Mueller
Right now, Oak supports very large properties (e.g. String). But 1 MB (or larger) properties are problematic in multiple areas like indexing. It is more important for software-as-a-service, where we need to guarantee SLOs, but it also helps other cases. So we should:
* (1) Document best practises, e.g. "Property values should be smaller than 100 KB".
* (2) Introduce "softLimit" and "hardLimit", where softLimit is e.g. 100 KB and hardLimit is configurable, and (initially) by default Integer.MAX_VALUE. Setting the hard limits to a lower value by default is problematic, because it can break existing applications. With default value infinity, customers can set lower limits e.g. in tests first, and once they are happy, in production as well.
* (3) Log a warning if a property is larger than "softLimit". To avoid logging many warnings (if there are many such properties) we then set softLimit = softLimit * 1.1 (reset to 100 KB in the next repository start). Logging is needed to know what _exactly_ is broken (path, stack trace of the actual usage...)
* (4) Add a metric (monitoring) for detected large properties. Just logging warnings might not be enough.
* (5) Throttling: we could add flow control (pauses; Thread.sleep) after violations, to improve isolation (to prevent affecting other threads that don't violate the contract).
* (6) We could expose the violation info in the session, so a framework could check that data after executing custom code, and add more info (e.g. log).
* (7) If larger than the configurable hardLimit, fail the commit or reject setProperty (throw an exception).
* (8) At some point, in a new Oak version, change the default value for hardLimit to some reasonable number, e.g. 1 MB.
The "property length" is just one case. There are multiple candidates:
* Number of properties for a node
* Number of elements for multi-valued properties
* Total size of a node (including inlined properties)
* Number of direct child nodes for orderable child nodes
* Number of direct child nodes for non-orderable child nodes
* Size of transaction
* Adding observations listeners that listen for all changes (global listeners)
For those cases, new Jira issue should be made.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)