Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
7.12.0
-
None
Description
In some circumstances it is possible that the order in which WebSocketProcesses are getting processed causes trouble.
In our case we have multiple items using a JS resource on a page. Each item has its own thread for WebSockets. The first arriving thread starts loading the JS, the next one may arrive before the resource has been loaded completely but will act like it is and call undefined functions. So the problem is the paralell processing where a resource is mistaken to be available.
I created a quickstart to reproduce the error, overriding the default WebSocketPushMessageExecuter, WebSocketPushMessage and implemented a Runnable. The page will try to load two images, executing a JS setting the src to a base64 encoded wicket logo (to increase size of the resource). One of the images will be displayed, the other one will fail to load. After it has been loaded, refreshing the site may result in both images beeing displayed, depending on your browser settings.
A workaround to make this work would be to use the Wicket.channelManager schedule to process. I provided the changed wicket-websocket-jquery.js where it is implemented. I had to pull the FunctionsExecuter into this file, because access in wicket-ajax-jquery.js is private.
I reproduced it for wicket 7.12.0 but it doesn't seem like this has been touched since then, so this might (or should) affect all versions since then.