Hi,
when I execute a long running operation in one tab (in one View), other tabs in the same browser become non responsive (any app View). They become responsive again after the operation in first tab completes. Application is running Vaadin 7.
If I access the application from different browser, everything is responsive.
How can I run long running operations without affecting other browser tabs?
Result of this long running operation is presented to the user when it is finished.
We are not using push technology, so basically result of the operation should come in server response.
I did some debugging and I think Vaadin session gets locked, and requests from other browser tabs try to acquire this locked vaadin session.
How can I run long running operations without affecting other browser tabs?
Different Tabs on same Browser have different UI instance but they share the same Session. And if you have long running synchronous operation, that will probably block the main thread and the session.
Different Browser is not sharing the session with the other Browser. Hence it is different thread that serves it.
How can I run long running operations without affecting other browser tabs?
The way to handle this kind of situation, to use asynchronous calls for long running operations. I.e. run them in sub threads using Executor service. And then update UI using ui.access(…).
We are not using push technology, so basically result of the operation should come in server response.
In order to tackle the issue you need to use Push technology, that is what is built for.
Different Browser is not sharing the session with the other Browser. Hence it is different thread that serves it.
Different requests from the same browser are also served in different threads, and they all wait for locked Vaadin session.
I tried to unlock and then lock the session when doing long operation like this:
VaadinSession.getCurrent().unlock();
// perfrom long operation
VaadinSession.getCurrent().lock();
I think that this temporarily releases the session lock, so other tabs can be properly serviced. After operations finishes, thread from the “slow tab” acquires the session lock again and sends response eventually.
It seems that this works (at least as a concept).
Is this workaround acceptable? Are there perhaps some issues with this approach?
Does this apply to non-UI related tasks as well? That is, we “sometimes” (not every time) see our UI lock up after doing a request that downloads data via a servlet (not via callbacks into Vaadin, but URLs that make requests of standard servlets). After the download, the entire UI is unresponsive, and we have to do a browser refresh to get it back.
Do servlet requests also need to determine if there’s a related Vaadin session/UI (presumably querying the HttpSession for some object) and lock them before returning data and then unlock at the end?
David Wall:
Does this apply to non-UI related tasks as well? That is, we “sometimes” (not every time) see our UI lock up after doing a request that downloads data via a servlet (not via callbacks into Vaadin, but URLs that make requests of standard servlets). After the download, the entire UI is unresponsive, and we have to do a browser refresh to get it back.
Do servlet requests also need to determine if there’s a related Vaadin session/UI (presumably querying the HttpSession for some object) and lock them before returning data and then unlock at the end?
We experience this lock up (we see vaadin progress indicator slowly moving on top of the screen indicating it is waiting for server) when we are waiting in UI view code. We are waiting for some slow service to finish executing, and then we just display small dialog box. We are not moving large amounts of data in servlet request/response. Nor we use response to download any kind of file.
I wonder why vaadin locks the vaadin session in the first place (so that other browser tabs stop responding)?
Perhaps it is because there is a possibility that same view is opened on different tabs, and this prevents the UI to go into inconsistent state.
If this is the case, then if we somehow know and can guarantee that all tabs show different views, it is safe to temporarily unlock the vaadin session like shown in my previous post.
When we design our vaadin UI’s we never allow a long running process to block the UI thread.
Locking the UI (with one tab or more) provides a poor UI experience.
We always push these task into a back ground thread.
We us the @Push annotation so we can notify the user when the task is complete.
Whilst the users waits you can put up a dialog with a ‘working’ message. Ideally the user should be able to cancel the task (remember if they can’t cancel it they will likely just refresh the browser anyway).
The other alternative is to use a notification area to tell the user when the task completes. This allows them to do other work until the task progresses.
There are lots of other UI design patterns for this type of work. The only one you shouldn’t use is the one you are using now
