Using SmartGWT 3.1d Power on Firefox 11 with IntelliJ IDEA Ultimate 11.1.3:
Sorry for the long post for what might require a trivial answer -- just being very thorough with the background info.
I'm wondering why DataSource.addData and .fetchData, which execute asynchronously, lock up the user interface while the server-side code is processing. For example, during a long-running operation on the server, I can't pick items off of a ComboBoxItem, click other buttons, and so on.
I'm not yet in a position to test this in hosted mode. I'm seeing this in development mode. Maybe that's the problem, but searching around in the docs and forums, I didn't see any discussion about this behavior or differences between dev and host modes in this regard.
I'm calling these methods via DMI. Here's a client-side test:
The server-side test is an intentionally stupid but long operation. The production system will perform data analysis lasting several minutes.
When I trigger this code from a button, I get output like this:
The "Called it." on line 2 above shows that things are indeed asynchronous.
In my test UI, I put a ComboBoxItem with a bunch of items in it and a ChangedHandler so that while the operation was running, I could try to interact with the combo and log the items that were being picked. But the comboBoxItem is inoperative during the above 15 seconds. When the fetchData callback is called, the busy cursor disappears and the comboBoxItem becomes operative again.
I only noticed this behavior recently when working on a very slow internet connection where the server-side processing, which is hitting Amazon's DynamoDB, bogged down for some reason. All the while (nearly 3 minutes) my UI was locked up. In the past, on a fast connection with AWS working normally, I never noticed the busy cursor in my app, as this operation typically takes less than 2 seconds. The test code above recreated what I experienced.
Thanks in advance for any insights, explanations and/or workarounds.
Sorry for the long post for what might require a trivial answer -- just being very thorough with the background info.
I'm wondering why DataSource.addData and .fetchData, which execute asynchronously, lock up the user interface while the server-side code is processing. For example, during a long-running operation on the server, I can't pick items off of a ComboBoxItem, click other buttons, and so on.
I'm not yet in a position to test this in hosted mode. I'm seeing this in development mode. Maybe that's the problem, but searching around in the docs and forums, I didn't see any discussion about this behavior or differences between dev and host modes in this regard.
I'm calling these methods via DMI. Here's a client-side test:
Code:
private final static int TEST_ASYNC_SECONDS = 15; DataSource ds = DataSource.get("test"); DSRequest request = new DSRequest(DSOperationType.CUSTOM,"doLongOperation"); Criteria crit = new Criteria(); crit.setAttribute("seconds",TEST_ASYNC_SECONDS); Log.warn("Calling fetchData"); ds.fetchData(crit,new DSCallback() { public void execute(DSResponse response, Object rawData, DSRequest request) { Log.warn("*** Back from smartGWT fetch."); } },request); Log.warn("Called it.");
Code:
public DSResponse doLongOperation(DSRequest request) { logger.warn("Starting long operation via SmartGWT..."); Long seconds = (Long)request.getClientSuppliedValues().get("seconds"); logger.warn(" Sleeping for " + seconds + " seconds..."); try{ Thread.sleep(1000 * seconds); } catch (Throwable t){ logger.error("Error with long operation..."); } return new DSResponse(); }
Code:
Calling fetchData Called it. Starting long operation via SmartGWT... Sleeping for 15 seconds... <<15 seconds later>> *** Back from smartGWT fetch.
In my test UI, I put a ComboBoxItem with a bunch of items in it and a ChangedHandler so that while the operation was running, I could try to interact with the combo and log the items that were being picked. But the comboBoxItem is inoperative during the above 15 seconds. When the fetchData callback is called, the busy cursor disappears and the comboBoxItem becomes operative again.
I only noticed this behavior recently when working on a very slow internet connection where the server-side processing, which is hitting Amazon's DynamoDB, bogged down for some reason. All the while (nearly 3 minutes) my UI was locked up. In the past, on a fast connection with AWS working normally, I never noticed the busy cursor in my app, as this operation typically takes less than 2 seconds. The test code above recreated what I experienced.
Thanks in advance for any insights, explanations and/or workarounds.
Comment