Hi!
I still returning to my previous quite simple question: how to kick server event on, let’s say, ProgressIndicator? E.g. I have a hidden ProgressIndicator and I want kick server periodically and refresh something on the page. However, when user closes browser, these “kicks” should stop. If I have a thread on server side and user only refreshes values, then thread continues to run.
Any thoughts?
Many thanks in advance.
How about stopping the thread on
Window close event
?
I doubt it catches browser window close or
nasty-ms-windows-
bsod
. 
Architecturally, it is correct to respond from the server, when it is asked for. Having an independent background process at server side for the user client is funny idea, since 1000 users will generate 1000 threads, then close their windows due various reasons (crash, mistake, intentionally, earth quake, moon phase, solar interference etc) and will generate one more time 1K threads after they back. So per 1K users I will have 2K threads. Oh wait, I would have also 1K threads from the appserver, since users are requesting me from the clients to update their UIs. So I will have 3K threads in total: 1K background threads, 1K lost background threads and 1K HTTP requests from users. Whoa! That’s just seems to be plain wrong way, IMHO (as long as I am not missing anything).
You probably want to say to user exactly as much as you’re asked for. No more. That’s it: client is pinging server for, let’s say, message updates, like in Twitter (never using it, but take it as an example). So how you, guys, suggesting to implement Twitter monitor online? Let’s say, how to get new set of messages periodically? (implementing UI part is completely clear for me).
I would probably do these enhancements for ProgressIndicator (just an idea):
private ProgressIndicator justRefresher;
...
this.justRefresher = new ProgressIndicator();
// this combination would eliminate various tricks to do the same
this.justRefresher.setVisible(false);
this.justRefresher.setAlwaysActive(true);
this.justRefresher.setImmediate(true); // this would kick server instantly
this.justRefresher.setPollingInterval(5000); // We don't need that too often
this.justRefresher.addListener(new PollingListener() {
public void onIndicatorPoll() {
MyGreatApplication.this.getLatestNews();
}
});What you think and why this idea must be bad? Goals are quite clear: no background dedicated thread, no ugly shamanic dance with a tambourine to make sure thread is terminated on time (well, almost on time, at its very best), it would be very easy to implement and, most important, closest sync with server and client (not the case if you have a background thread and client also polls updates). Basically, create a simple invisible Button that will click itself periodically.
P.S. And how to stop the threads if user session over, BTW? Running a yet another thread that is just iterates through sessions and is ripping off whose session gone?.. 
In that case I will have 3001 thread. :lol:
Hi!
Vaadin actually detects the browser window close, but the BSOD situation is quite hard to catch indeed.
The idea of PollingListener don’t look that bad to me. It might be simplify things a bit in some cases. In cases I have seen for theProgressIndicator there is the other thread, but I can easily figure out situations where it would need to be created just to update the indicator.
The implementation should be trivial in case you want to submit a patch. At least, create a ticket for it.
Override the application close() method. Vaadin automatically closes the application when session is dead.
cheers,
matti
Hi,
Chiming in with additional thoughts…
The listener idea is obviously good, one wonders why that’s not implemented already.
However, you don’t actually need one extra thread for each client, though - you can have one thread that fetches the results, and updates each client’s UI as appropriate - this way there will be changes waiting when the client polls. It does require a small shamanic
synchronize on application
dance, however (tambourine not needed).
Also, as for knowing when the client has bsodded, if it’s supposed to poll once every fortnight, you can probably safely assume it’s stopped if no polling has occurred in, say, two fortnights. This probably will require a tambourine, though, since the progressindicator is missing a listener. Also note that the session will eventually timeout, you might be able to use this to your advantage.
The listener approach would make things much easier in most cases though, although you might want/need a combination of tricks depending on the situation.
Best Regards,
Marc
Hi!
Well, yes, as long as your data is common to everybody. But if you fetching “…WHERE USERID = …” — then each user needs to have their own continuous thread on the server.
Taking so much CPU and electric power waste is not environmentally friendly nowadays. Vaadin should be definitely “greener” here.
Actually - there is no need for extra threads in the case where data is user specific. Just maintain a list of weak references to applications that need to be polled. The polling thread can then ask about user identity from each.
One thread should be enough for everyone :)
Or a small pool of threads processing the same queue of applications, if you expect some of the requests to get blocked for a while. A little more complexity but may reduce the typical refresh delay.
Then some more (well, much-much more) complexity when you’re (like me) is running on a true cluster of GlassFish’es in order to sync thread jobs between nodes to prevent “jumping effect” and other stuff like that. So in order to automatically click a button, there needs to be THAT MUCH WORK to be done?
Uhmm…
Why this funny and tremendously über-complex way to do a very simple task in the way like a scratch an ear via-under leg here with a strange design and pattern, if there could be just a simple straight-forward refresher listener that could get a data when it needs and how much it needs? This also requires a zero effort in order to run such portlet (or web app) on a clustered environment. Also, since users are anyway doing their requests to refresh the data from UI — why not just reuse their own requests anyway, reduce this unnecessary complexity and rely on a server, which will take care of when start/shut down a particular thread?
In fact, appserver already offers threads and requests. So if you have your queue and a daemon thread, then you’re like a building an embedded server within an application server. This is very odd approach to me. I haven’t even started ranting that this is a clear bottleneck for a performance scalability and clustering.
But, honestly, I don’t understand why proposed listener is a bad idea, but maintaining such Frankensteins is OK…
Bo cries
Bo - you are absolutely correct. I was just commenting that IF you are going to do it with threads, then one thread should be enough.
So the selection is between push and poll:
If you are going to do it from UI, then any client-side polling mechanism will do - use refresher for example. Then just
add a TransactionListener
to the application context and do the updates there.
If poll, then transaction-listener should be ok. If push, then you need a (single) thread on the server-side to push when needed - with ICEPush for example.
I read that ICEpush add-on (or generally ICEpush, ICEpush.org) has sth like heartbeating, see here
http://vaadin.com/forum/-/message_boards/message/168956#_19_message_168956
.
I can’t get any response how to connect server side sending queue with .push() method but if there is any ping-pong checking then server can know if client crashed.
Also to not to have so many threads you should consider to start to using Scala and their great actors model. I heard that there are actors implementations for Java but in Scala everything is much easier. On 4GB machine you can have 6 000 000 actors but only 100 threads.
If http server is using NIO (or NIO2) technology there will be only one thread to utilize all network traffic (accepting connections, reading, writing, closing connections). Is http server (I gues servlet container) is using thread pooling there will be even less threads.
Well, since you’re author :vader: of these obscure API’s then at least there is who can get blamed for them, ha-ha!
TransactionListener actually worked fine for me, many thanks. On transaction open, I update stuff and update UI. On transaction close user gets updated UI. Looks reasonable. The only thing I don’t really like: it is app level, so things might look messy. But it is possible to live with that like this at least. And for some other reasons app parameter is always null, but probably that’s a time to explore API more in detail.
BTW, another little hint: if you know that session expired and you showing that fancy red alert “Communication Failure, click here etc” — them maybe it is reasonable also disable all the polling automatically, unless user clicks that red thing? — just my few cents here…
P.S. http://vaadin.com/directory#addon/125 — interesting. As long as it works… :lol:
Uhmm… I might have to re-read this thread, but I was under the distinct impression that everyone thinks
the proposed listener is a good idea.
It would certainly be a lot easier in many cases. The rest of the discussion is about alternative solutions, and how to thread lightly - because you might still want threads in some situations.
Make a PullFromListener add-on! 
Best Regards,
Marc