I’m currently in the process of improving a small application which does not much but displaying some information, a clock and executing a sql command.
My clock works using one thread for each application instance and the built-in Vaadin 7.1.0.beta1 polling mechanism. Now when i test it i can see that the thread and/or the Polling sometimes happens asynchronous even on the same machine in different browsers.
Now i thought about whether it would be possible to make the thread and the polling completely synchronous. One step would be to maybe make the thread static so that only one instance runs on the server for all UI’s. The only question i have is: How to make the Polling as synchronous as possible?
One way i thought about was: I recalculate the time, the thread will sleep until the next minute, because for some reason i can’t get it to work with just using 60000 ms (one minute). As a result i reassign the Thread.sleep value and also the polling interval every minute. If i do that the same thing in the static thread would this make it “completely” synchronous (let’s ignore connection speed for a second)?
Hope to hear your thoughts.
Regards,
M.R.
PS: Just tried and UI.getCurrent() in the static thread returns null. IS there a way to get the UI instance without having only one static UI?
Also i need to call a void which uses non-static variables. So it can’t be static. Is there a way to call this from the static thread or should i use a separate thread for this?
First see the example
Broadcasting messages to other users . Alternatively, you can get and iterate over the list of all UIs. You need to make sure that you lock each UI separately while accessing that UI. I’m afraid also that example might have some problems in how it handles locking, though it might be ok with the latest changes to the semantics of UI.access().
UI.getCurrent() returns the correct value within an UI.access(Runnable), elsewhere it is not defined.
Getting locking correct in such a system is tricky, it is very easy to write an application that might end up in a deadlock (if you lock two UIs simultaneously) or block UIs unnecessarily. The latest 7.1 snapshots have modified how UI.access() works to reduce the potential for deadlocks somewhat.
Making things completely synchronous won’t really work if your UIs can block requests for any significant length of time on the server. To get as close to synchronous as possible, you would need either a thread for each UI or a system that maintains a pool of UIs to notify and picks available ones (those not locked) until all UIs have been notified.
Replacing explicit use of threads with a (shared?) Executor scheduled to trigger e.g. every minute might also be a good idea, but note that it does not eliminate the need for locking. Nevertheless, it would be more in line with what current JEE specs allow.