Recursive calls leading to an OOM when parsing a valid schema #1016
Comments
|
I attach the problematic schema here too, for convenience. |
|
Unfortunately this typically means that there's not enough memory to load your schema and you would need to allocate more heap for your JVM. Previously the default was to lazily load the schema. Now the default is to preload the schema. You can still configure it to lazily load the schema with the @Test
void testNoErrorsForEmptyObject() throws IOException {
SchemaValidatorsConfig config = new SchemaValidatorsConfig();
config.setPreloadJsonSchema(false);
getJsonSchemaFromClasspath(resource("schema.json"), SpecVersion.VersionFlag.V7, config);
}However, you should note that if you have inputs that exercise all the possible evaluation paths of your schema as defined, then it's just going to OOM later when if validates such an input. |
|
That seems... improbable, @justin-tay ? I mean - this schema is not that large (or complex). Something seems wrong if it needs in excess of gigabytes of memory to load validators for a mere 300kb? |
|
The state of the validators / schemas are different along the evaluation path. Therefore the code will need to create validator / schema instances at each evaluation path to store this state. This is cached since throwing it away impacts performance as this state is fixed for a particular schema. Throwing it away means that the same state needs to be regenerated between each run and also increases the objects that need to be garbage collected. The following is a small sample of the evaluation paths that get loaded for your schema. Looking at this it looks like even if you don't preload, you could still potentially get an OOM during execution if you have inputs that exercise the evaluation paths and if you don't want to allocate memory for all the evaluation paths as there is currently no option not to cache the loaded schema during the run itself. This probably needs more memory than the consolidated FHIR schema, which like a 4 MB schema so it's not really the size in bytes of the schema itself. |
|
Right, I see it now. It's the fanout on evaluation of refs then - you can easily make this exponential and crash schema parsing even with a very small input. It's basically what's happening with the example I attached. Thank you for looking for a workaround - I don't think multiple refs are going to be that uncommon in the wild, so it's probably good to have an option to turn off caching. |
Hello!
I've been trying to upgrade our project to the latest version but detected an issue where the validator causes an OOM with a schema that previously worked just fine (and validates against other on-line validators). This commit in my fork reproduces the problem:
dweiss@cefbf5b
It seems to be somewhere around the loop initializing validators:
It's not clear to my why this doesn't end with a stack overflow - instead, it just leads to an OOM, almost as if it were fanning out somewhere (there are lots of refs in that schema).
I didn't dig deep but I thought you folks would be interested and would have more expertise to tell what's going on. Thank you.
The text was updated successfully, but these errors were encountered: