I am not very experienced in this area but I guess the original behaviour is correct. EJB spec 4.8.5 Singleton Session Bean Concurrency states:
Independent of the bean’s concurrency management type, the container must ensure that no concurrent
access to the singleton session bean instance occurs until after the instance has successfully completed
its initialization sequence, including any PostConstruct lifecycle callback method(s). The con-
tainer must temporarily block any singleton session bean access attempts that arrive while the singleton
session bean is still initializing.
and TestReader @PostConstruct already happened.
Interesting. Then this would be a Wildfly 10.1.0 bug? Where could I report it?
I think It should go to WFLY project not WFCORE. Thanks
You are right. As I don't know how to change category, the Wildfly developer must take care of this.
I haven't looked at the application you attached, but what exactly is blocked? The call to singleton bean B from the @PostConstruct of singleton bean A? And when you say blocked, can you get the thread dumps (a couple of them in intervals of around 3-5 seconds)? Also, is singleton bean A a @Startup singleton or a regular singleton?
Thank you jaikiran pai for changing the category to WFLY - [WFLY-7101] Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct - JBoss Issue Tracker
> ... what exactly is blocked? The call to singleton bean B from the @PostConstruct of singleton bean A?
This direct call works as the suplied example code shows - the call to singleton bean B is blocked
if done from a thread created with a ManagedExecutor from the @PostConstruct of singleton bean A.
> And when you say blocked, can you get the thread dumps (a couple of them in intervals of around 3-5 seconds)?
Just execute the example I supplied - the @Postconstruct thread waits 10 seconds and during this 10 seconds
the 4 created threads are blocked and they continue to run after the @PostConstruct thread has left the method.
> Also, is singleton bean A a @Startup singleton or a regular singleton?
I made it @Startup for demonstration purpose, the bug appeared first in a non-@Startup singleton bean.