The problem is that the requestParameter maps in the ExternalContext (BridgeExternalContext and ServletExternalContext) are not protected by synchronization.

The example application I had included several text input fields each triggering an event on loss of focus. Holding the tab key down generates a rapid stream of requests to the server, all intended for the same ViewRoot, (and ExternalContext instance). The stream of requests is so rapid that a thread (eg. HTTP-1 ) is in the renderResponse phase while the next request (eg. via HTTP-2) has arrived and is progressing through the MainServlet. The problem arises in the ViewBoundServer which calls update on the ExternalContext instance without any synchronization.

At the very least, this puts the values in the request parameter maps at risk of concurrent modification by the incoming thread while the current thread is executing or rendering in the JSF lifecycle. In my example, there's a very short window of time when the new request parameter maps don't have any values at all, and occasionally (extremely rarely actually), Spring webflow would not unlock the webflow properly (since the webflow key could wasn't found in the externalContext.getRequestParameter map, leading to a complete server deadlock.

Note that it's possible to construct the new maps and copy values into them, and then swap references to them which alleviates the problem with my missing parameters (since the request continually contains the same parameters, any version will do) but that doesn't fix the problem if the request parameters are changing with each new request potentially overwriting parameters from the immediately previous request.

I think we need to move the synchronization protection to a position that protects all contents of the View for the duration of any single request.