You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TCK Challenge InheritedAPITests#testApiScheduleAtFixedRate and InheritedAPITests#testApiScheduleWithFixedDelay, tests don't use a Singleton EJB as counter
#261
Closed
emmartins opened this issue
Jul 29, 2022
· 2 comments
Both tests lookup and use an EJB to count task runs, yet such EJB is Stateless and the counter is local to each EJB instance provided by the container. There is no spec guarantee that each JNDI lookup will return the same EJB instance, which means that if a container uses an EJB instance pool, and provides different EJB instances to each task execution, the counter value which the test uses to assert the result will not have the correct value.
Here is an example of the issue with the CounterSingleton EJB code modified to print the instance and counter value, on each business method:
2022-07-28 11:59:42,449 INFO [ee.jakarta.tck.concurrent.framework.ArquillianTests] (default task-2) --> testApiScheduleAtFixedRate
[ testApiScheduleAtFixedRate ]
2022-07-28 11:59:43,452 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-12) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 1
2022-07-28 11:59:44,456 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-12) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 0
2022-07-28 11:59:45,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-12) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 2
2022-07-28 11:59:46,456 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-13) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 1
2022-07-28 11:59:47,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-8) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 3
2022-07-28 11:59:48,455 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-8) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 2
2022-07-28 11:59:49,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-8) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 4
2022-07-28 11:59:50,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-7) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 3
2022-07-28 11:59:51,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-7) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 5
2022-07-28 11:59:52,454 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-9) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 4
2022-07-28 11:59:53,452 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-4) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 6
2022-07-28 11:59:54,454 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-16) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 5
2022-07-28 11:59:55,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-16) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 inc: 7
2022-07-28 11:59:56,454 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-16) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 6
2022-07-28 11:59:57,452 INFO [stdout] (default task-2) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 get: 8
2022-07-28 11:59:57,453 INFO [stdout] (EE-ManagedScheduledExecutorService-default-Thread-16) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@3d0b3524 inc: 7
2022-07-28 11:59:58,454 INFO [stdout] (default task-2) Counter ee.jakarta.tck.concurrent.common.counter.CounterSingleton@15a07b40 reset: 8
The fix is simple, change the CounterSingleton from @stateless to @singleton (which was the original TCK code), at
Specification:
Jakarta Concurrency 3.0.0
Challenged test(s):
ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.inheritedapi.InheritedAPITests#testApiScheduleAtFixedRate
ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.inheritedapi.InheritedAPITests#testApiScheduleWithFixedDelay
TCK version:
3.0.1
Tested implementation:
WildFly 27.0.0.Alpha4-SNAPSHOT (branch)
Description
Both tests lookup and use an EJB to count task runs, yet such EJB is Stateless and the counter is local to each EJB instance provided by the container. There is no spec guarantee that each JNDI lookup will return the same EJB instance, which means that if a container uses an EJB instance pool, and provides different EJB instances to each task execution, the counter value which the test uses to assert the result will not have the correct value.
Here is an example of the issue with the CounterSingleton EJB code modified to print the instance and counter value, on each business method:
The fix is simple, change the CounterSingleton from @stateless to @singleton (which was the original TCK code), at
concurrency/tck/src/main/java/ee/jakarta/tck/concurrent/common/counter/CounterSingleton.java
Line 21 in d1a608c
I will submit a PR with the fix.
The text was updated successfully, but these errors were encountered: