Hi,
Hi,
In the past I've been bitten a (very) few times by performance issues
caused by the "only one ongoing request per Page instance per session"
limitation in Wicket.
My use-cases were:
1.) displaying a huge number (>100) of dynamically rendered images
(charts) on a single page
2.) displaying a "dashboard"-style page with a number of individual
panels that each refresh independently
Case 1.) I solved with a hacky solution that puts the images into a
HashMap served by a tiny servlet and using links pointing to the servlet
instead of using DynamicImage in the generated markup
For case 2.) I couldn't come up with a solution yet (maybe someone else
solved this already ?).
Sure!
You can use Wicket WebSocket backed by a Resource.
http://examples8x.wicket.apache.org/websockets/resource
<http://examples8x.wicket.apache.org/websockets/resource;jsessionid=D94FD13A27B7757D34B90997FDC1BB35?0>
is
the demo.
Source:
https://github.com/apache/wicket/blob/a4b92a4322ec00832afc2fdbe2d885ca476ba6c5/wicket-examples/src/main/java/org/apache/wicket/examples/websocket/WebSocketResourceDemoPage.java#L31
Thanks for the pointer, will look into this !
Not sure if this is even possible with the current architecture of
Wicket - but are there any plans to make wicket-core thread-safe so
Components could serve requests in parallel ?
No such plans.
Making such change in Wicket will require *all* applications to deal with
this problem by themselves.
That's not exactly what I had in mind. I was more thinking along the
lines of
1. Making the wicket internals (request handling, page graph mutation,
resource handling etc, including o.a.w.Component class itself) thread-safe
2. Add an overridable Component#isThreadSafe() method that returns false
by default
3. Have a Page#isThreadSafe() method that checks that only thread-safe
components are used on a page
4. Only use the per-session PageLock if a Page#isThreadSafe() returns false
The main problem I see (aside from the fact that it's really hard to
retrofit thread-safety in a codebase that was not designed with this in
mind in the first place) is that mutating the page component graph
concurrently may lead to different results depending on the execution
order of HTTP requests ... probably too error-prone.
Cheers,
Tobias
Cheers,
Tobias
--
Tobias Gierke
Software Developer
Voipfuture GmbH Wendenstr. 4 20097 Hamburg Germany
Phone +49 40 688 9001 64 Fax +49 40 688 9001 99 www.voipfuture.com
Managing Directors Jan Bastian Eyal Ullert
Commercial Court AG Hamburg HRB 109896 VAT ID DE263738086
