Fix for deactivating managed context in GraphQL server

[phillip-kruger]

Fix #27036

Signed-off-by: Phillip Kruger [email protected]

[quarkus-bot]

Failing Jobs - Building 308aae0

Status	Name	Step	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11	Build	Failures	Logs	Raw logs
✔️	Gradle Tests - JDK 11 Windows

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.CompositeBuildWithDependenciesDevModeTest.main line 24 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[gsmet]

Why isn't this one in a finally? Why deactivate in one case and terminate in the case of an exception?

Also what's the purpose of this.currentManagedContextTerminationHandler now?

[phillip-kruger]

this.currentManagedContextTerminationHandler will terminate (so deactivate and destroy) once we are done, while the deactivate after the handleWithIdentity will only deactivate (so that it does not leak)

[phillip-kruger]

It does not need to be in a finally as the catch with terminate

[gsmet]

I can understand that but my concern was more that we are not consistent. Typically here: https://github.com/quarkusio/quarkus/pull/27040/files#diff-5b5cda47e6a5418c9345a577d468f058e05c412dc9b64fce6a6ef5aec496023bR75-R85 where we simply deactivate. Or maybe the exception from the latter is caught below?

Also what do you mean by leaking? What I don't understand is how we can leak something between this and the end of the response? Or is it that the thread is somehow reused between the end of this and the end of the response?

[phillip-kruger]

The thread could be reused, in a high traffic scenario.

[gsmet]

But you're sure that all the response handlers we added earlier are always executed on the right thread at the right time?
That's what gets me a bit worried.

Note that I have no idea how this all works so I'm asking naive questions.

[phillip-kruger]

Yes sure. Maybe @stuartwdouglas can explain better. By leaking I mean that a new request that use the same thread can get the context that still float around (because it's not been deactivated)