I've just re-tested with the lates WF 10 Final Release and the Problem still exists, It seems that access to stateful beans is not synchronized anymore or the requests are not handled in correct order, which is the case in <= WF9.
Am I the only one experiencing this kind of problem or is there a setting I am missing?
We're still having the same issue with Wildfly 10.1.0.Final.
Can anybode help us with this?
I think the question in your original post is a bit too complicated to understand. Can you narrow down this issue to something more specific and testable/reproducible in a simple application?
Sure, I've uploaded a simple eclipse project:
(Sorry, could't find another place here to upload ist)
Just deploy on WF 9.0.2 and WF 10.1.0 and goto:
The index.xhtml is configured to call a Stateful Session bean and increment a counter on each page refresh.
So just hold down the F5 key and see the different behaviour in WF9 and WF10. In WF9 the requests are handled sequentially and the Server returns the response of the last request. In WF10 I see an intermediate request being answered and sent back to the browser. The problem here is, the following requests are still being processed (just watch the console-output) and new ViewStates are being created. At some point the returned page will become unavailable due to a ViewExpiredException.
I hope this helps to clarify the situation.
Can anybody help?
Same problem with 11.0.0.Alpha1.
We cannot figure out how to solve this or find the correct configuration option (if there is any) to change this behaviour.
However, I think it is somehow related to the HTTP/2-changes (although we've disabled any http2-option).
As this is a major problem in any jsf-based application using SFSBs I'm wondering if anybody else have experienced this?
I tried to reproduce this issue and got an error 'could not obtain lock within 5000 MILLISECONDS'.
Seems to be resolved when increasing the 'Default stateful bean access timeout' like
The problem in question is not actually the ConcurrentAccessTimeoutException, but the order in which the responses are sent back to the browser.
For example: The client sends 10 request, but the server only delivers the response of the 5th request, but processes all other requests as well, as you can see on the console (and in case of jsf also creates new viewstates which may lead to ViewExpiredExceptions on following requests).
In WF <= 9 this wasn't the case, as the client would wait for the response of the last request.