Potential timeout error

[ThomasJejkal]

Describe the bug
I ran into this issue while operating the Typed PID Maker behind a Spring Cloud Gateway, but it may occur in all setups. The issues occurs if creating a Typed PID with "many" unknown types the first time. The Typed PID Maker resolves all types and caches them for subsequent calls. However, the first time a type occurs will cause some delay and multiple of these delays may sum up to the configured timeout for a single call. In my example, the response timeout was set to 5 seconds, which was hit reliably e.g. for PID Records with 10 previously unknown types.

As a suggestion I would document to increase the timeout to a much higher amount, e.g., 30 or 60 seconds, to be on the safe side.

[Pfeil]

Just to clarify: The timeout appeared in a configured HTTP reverse-proxy in the setup (or the Spring Cloud Gateway, in this case), not in the Typed PID Maker (configuration), right? The Typed PID Maker itself should not time out, of course.

There are two "heavy" things that happen on validation:

1. http requests (to the DTR // resolving records) take relatively long and benefit a lot from asynchronous execution
2. JSON validation

• the validation of each attribute is independent of the other attributes. It should be easy and beneficial to parallelize or use asynchronous code.
• by far not as heavy as http requests as everything is very fast if the cache is filled. The issue is definitely the amount of requests and maybe parsing/serializing the responses.

TODO

• update documentation about this issue → fix soon
  • PR for webpage: Typed pid maker version 1.1.0 webpage#32 (merging depends on https://github.com/kit-data-manager/pit-service/milestone/2)
  • Swagger documentation: docs(swagger): add hint about validation time #140
• midterm: parallelize/asynchronize type resolution and validation.
  • Validation parallelization could be done in Fix 114 Unclear/non-standard response for post api/v1/pit/pid #125, as the validation was rewritten in there anyway, or we wait for it being merged and set it on top.
  • In either case, this means this part would belong to Milestone 2.0.0 or later. I will therefore change the milestone accordingly.
  • The old validator could be kept for some time, in case the parallel implementation will have issues in some cases (testing phase)
  • This seems to be the easiest way to do async. Uses Java and Spring. But it is likely better to remove the guava cache and use this fast and optional async cache called caffeine, which seems to be available in spring already. This seems to avoid a lot of async boilerplate for us.

[Pfeil]

A full rewrite using async and virtual threads, as well as several optimizations, is being done in #218. It also implements Schema Generators, which I believe could be interesting for #179. I hope I'll find the time to do some proper benchmarks between main (2.x) and #218 (which will likely result in v3.0.0 or so, as we consider removing implicit profile validation for compatibility reasons with other project and make it optional/explicit).

[Pfeil]

Just a small remark that I consider the performance issue basically solved with #218, and it will land in a soonish available version. Usual performance on machine is 180ms with empty cache, and 3-5ms using the default configuration. It is not fully decided yet if it makes into the 2.x series or the 3.0.0 preview which we are planning.