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)