[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] TCK test ContextServiceDefinitionServlet.testContextualFunction randomly failing
|
Nathan,
great, thank you.
The challenge:
https://github.com/jakartaee/concurrency/issues/253
PR with the test disable:
https://github.com/jakartaee/concurrency/pull/254
Petr
On 7/7/22 20:18, Nathan Rauh wrote:
Petr,
Yes, you
should challenge that test. Its assertions on results[0]
and results[1] are both invalid because treating those two
UNCHANGED context types as though they were CLEARED.
Hi,
I have a question for the developers of Glassfish-based
servers and Nathan.
It seems, that there is one more test to challenge --
ContextServiceDefinitionServlet.testContextualFunction.
This test expects, that a thread with unchanged
APPLICATION will have
JNDI disconnected from the app, e.g. java:module lookup
will fail.
I already created a challenge for a similar issue:
https://github.com/jakartaee/concurrency/issues/224
. The test would work
best with APPLICATION in cleared.
Glassfish implements invocations in InvocationManagerImpl
and stores
them in
InheritableThreadLocal<InvocationArray<ComponentInvocation>>
frames. This means, that any thread created from an http
thread will
have a context.
The current problem is, that RANDOMLY, some ForkJoinPool
thread are
created from the http threads. Then the context is
available and the
test fails.
Should I create another challenge?
Petr
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
