ContextPropagationHelper has a high memory overhead

[iuliiasobolevska]

Hi Folks,

A canary run on one of our high-RPS services showed a significant performance degradation when upgraded from spring-graphq@1.3.4 to 1.4.0. We skipped the last OSS Spring Boot 3.4 version (3.4.7) and jumped on 3.5, so we have never tested spring-graphq@1.3.5.

The flamegraphs show that ContextPropagationHelper.isCancelled() method allocates 3GB of memory:

Potential issues:

1. https://github.com/spring-projects/spring-graphql/blob/main/spring-graphql/src/main/java/org/springframework/graphql/execution/ContextPropagationHelper.java#L128-L129 creates a publisher that's stored in context. Shall there be a cleanup mechanism to remove it from the context?
2. ContextPropagationHelper.bindCancelFrom() calls: https://github.com/spring-projects/spring-graphql/blob/main/spring-graphql/src/main/java/org/springframework/graphql/execution/ContextDataFetcherDecorator.java#L127-L134 may be creating additional reactive chains that maintain references.
3. https://github.com/spring-projects/spring-graphql/blob/main/spring-graphql/src/main/java/org/springframework/graphql/execution/ContextPropagationHelper.java#L143 repeatedly converts Mono to Future with Futures and their associated reactive chains potentially accumulating in memory.

[bclozel]

This behavior has been introduced in #1149.

Right now I don't think there is a memory leak, but most probably the overhead is too important for a many-datafetchers + high RPS environment. We're exploring a couple of solutions, one being only preventing further data fetching operations and not cancelling in-flight ones. That would significantly reduce the cost of this.

Note: this feature is a temporary fix, until this is natively supported in graphql-java - see #1171.