Welcome to our little christmas present. The application in this repo was done for the Senacor DevCon Conference this year. It showcases different approaches to asynchronously loaded contents.
THIS CODE IS INTENDED TO SHOWCASE DIFFERENT APPROACHES AND IS NOT INTENDED FOR PRODUCTION USE
There is a common problem in a lot of web applications: At some point you will have to wait for a long running process to finish (e.g., a slow database query or another system integrated via webservices).
If your whole application gets stuck on a simple counter being loaded from the database you will be starting to look for better options.
We tried out several ways of dealing with this problem and put together this little application to showcase the different approaches.
Under the hood we use Spring-@Async to deal with long running processes. To interact with them, we created com.senacor.wicket.async.christmas.widgets.api.model.AbstractAsyncModel. We also added some delay-functionality to REALLY make sure things would take some time ;)
But the main focus lies on how to deal with these models which will be explained further down.
After checking out, import it into the IDE of your liking. As it is based on the Wicket Maven Archetype, you will find com.senacor.wicket.async.christmas.Start in the test-folder. Use mvn jetty:run to run the application or you could run Start directly if your IDE supports aspectj. The application uses aspectj for the spring integration, so you need the aspectj-support in your IDE (aspectj-tools, if your are using eclipse). The application is running in development mode by default, so there won't be any outgoing traffic. If you are feeling adventurous you could switch to production-mode by providing -Dspring.profiles.active="prod" as a jre parameter. Now go to http://127.0.0.1:8080.
Accessing the application, you will find four links leading to the different implementations. On each page you will see a Request Counter displaying the amount of requests sent to the server (take a close look) and three panels.
The top most panel displays train delays in Germany taken from http://zugmonitor.sueddeutsche.de.
Number two uses Spring Social to display the results of a query to the public Twitter time line.
Third and last you get Dilbert comics from their RSS-feed.
Each one takes considerable time to start up, which we are trying to hide behind a spinning component.
This version is built on AjaxLazyLoadPanel, which is part of the Wicket core distribution.
We were trying to use some wicket AjaxLazyLoadPanel and expected to have parallel requests to the application.
Advantages
- easy to implement
- a single request per lazily loaded component Disadvantages
- blocks on the first call
- components have to wait in call order
- depending on the order of requests, fast loading components will have to wait for slower ones to finish
- things can get very complicated in complex component hierarchies
- Conclusion: It's not possible to process real parallel requests from a page. So, in the next examples we decided to implement the async loading part on the model level instead of the component level. That way, the long time loading can be parallel as well as asynchronous to the alien systems (twitter, dilbert and zugmonitor), and we make short and efficient update-requests from our page to the application.
This version uses an AjaxSelfUpdatingTimerBehavior to periodically check if the content is available. When the content is loaded, it replaces the spinner. Advantages
- slightly more complex than AjaxLazyLoadPanel
- won't block on the first call, allowing components to be updated as they come Disadvantages
- a lot more requests are sent to the server About the name: you will understand the name after reading the next paragraph.
Instead of registering multiple AjaxSelfUpdatingTimerBehaviors we decided to register a single one and use it as a Heart Beat. Each time this Behavior sends an update, we send a HeartBeatEvent into the component hierarchy. Each component listening to these events has to tell the application whether it needs further beats. If this does not happen, the Heart will stop beating. Advantages
- requests are reduced to the bare minimum
- even complex hierarchies are easily handled as heart beat consumers can be placed anywhere Disadvantages
- slightly more complex to implement
Using the wicket native websocket implementation. Advantages
- Server push - this is what we really want for our application
- cool stuff - everybody wants websockets :-) Disadvantages
- the websocket implementation is experimental - during the implementation, we had a lot of strange exceptions and erros
- the wicket native websocket implementation is not very well documented on the web. We found only two useful links: http://splitshade.wordpress.com/2012/11/04/wicket-6-2-websockets-und-jquery-visualize-die-richtige-atmosphare-schaffen/ and http://wicketinaction.com/2012/07/wicket-6-native-websockets/
- The example from the web uses an AjaxLink and sends a websocket message. But this is not the case we want, because there is no advantage compared to a normal ajax request. We need an active server push example.
- Our implementation uses custom threads on the server side, but it is impossible to update an wicket component from our thread, because there is no RequestCycle. Without a RequestCycle wicket cannnot render components, so we are sending a simple update-text-message from the thread. If the Page gets this update message, an update request is created, and during the update request the components are rendered and replaced.
Enjoy, Olaf and Jochen
Olaf Siefart
Jochen Mader
Contributions:
Pictures included in the application were taken from Flickr and are licensed under Attribution 2.0 Generic:
User apparena https://secure.flickr.com/photos/gigold/4241835169/
User Thomas Gigoldhttps://secure.flickr.com/photos/gigold/4241835169/
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent