Hi Andrea,
I guess you know that Wicket synchronizes the access to a page instance in
Wicket 1.5.0+, in 1.4.x and before it was by pagemap.
This is done to simplify user applications to care about synchronization
while dealing with the page's components.
WebSocket communication is no exclusion. If there was a way to access the
same page instance from several (WebSocket) requests then you are in a big
trouble.
WebSocket is full-duplex, i.e. you can read and write simultaneously. So
far so good.
The problem occurs when the web container uses different threads for
processing the WebSocket frames.
In Tomcat when using BIO connector (i.e. old IO) it uses *one* thread per
WebSocket connection, so you can access the page instance "immediately"
because Wicket's PageAccessSynchronizer supports reentrant access. But
"immediately" actually means "as soon as the thread is able to process the
new frame", i.e. when the previous blocking operation is finished.
When using NIO connector (I think APR as well) Tomcat uses a thread per
frame. I.e. processing of the frames have to wait for access to the page
instance. So the actual behavior from the user application point of view is
pretty much the same.
Wicket Native WebSocket by default opens a WebSocket connection as soon as
the page is loaded, so you can use Wicket.WebSocket.send(...) (JavaScript)
and listen for pushed data with Wicket.Event.subscribe("/websocket/message",
function(jqEvent, data) { ... }) without any other preparations in your
code.
You can open more WebSocket connections with: var myWS = new
Wicket.WebSocket(); too but really there is no gain in doing this. Actually
it may lead to higher usage of resources at the server side.
You can implement full non-blocking behavior by using Wicket Resource
instead of Page. But in this case you should update the page view with
JavaScript and use the WebSocket connection to update the server state
(e.g. store data in DB, Session, etc. but not in Page's components) and to
receive updates from the server (e.g. updates from a job scheduler).
Writing this I realize that maybe non-blocking behavior could be achieved
by making WebSocketBehavior stateless. At the moment as all Wicket Ajax
behaviors WebSocketBehavior is stateful. But I guess a stateless page with
WebSocket should work similar to Jolira's Stateless Ajax behaviors.
On Tue, Apr 16, 2013 at 8:46 PM, Andrea Del Bene <[email protected]>wrote:
> Hi,
>
> I'm playing around with JSR 356 (its final ballot should finish on 22
> April) and I come out with an issue that involves also the current support
> for native websocket. In my project (you can find it at
> https://github.com/bitstorm/**Wicket-tutorial-examples/tree/**
> master/JsrSocketExample<https://github.com/bitstorm/Wicket-tutorial-examples/tree/master/JsrSocketExample>)
> I've used the same method 'broadcastMessage' implemented in class
> AbstractWebSocketProcessor.
> The problem I've found with this method is that it retrieves a page
> instance with the current page manager before processing the socket
> message. The side effect of this code is that the page is locked for the
> entire duration of message processing. This means that we can't have
> multiple socket behaviors running on the same page at the same time.
> In other words, a long-time running behavior will block any other
> websocket behaviors waiting for the page instance to be unlocked.
>
> How would you cope with this problem? Maybe creating a family of behavior
> that doesn't retrieve its page via page manager?
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
