Databound listgrid's datasource never returns. Race condition?

[kcsaszar@anstca.com]

Dear SmartGWT Team,

Version:
SmartClient Version: SC_SNAPSHOT-2011-01-06/PowerEdition Deployment (built 2011-01-06) / GWT 1.7.1

Browser:
Internet Explorer 8 on Windows. I'm using NetBeans 6.9.1 which I believe uses the OS's IE in the IDE, where I get this error.

Background:
When I call fetch data on a data-bound list grid, the appropriate call on the service gets invoked. That method puts together a neat looking list of columns (i.e. no nulls, or anything unusual), and returns to handleDSRequest which just never seems to return to the client. It looks like the app crashed!

To test if it really never returns, I put a data arrived handler on the grid with a simple SC.say(..) message box. To my surprise the box popped up, so the data service returned the data to the client. Now if I hit ok on the box, the data is in the grid. But if I take the message box out, there is no data in the grid, and 'Contacting Server...' is stuck on the screen forever.

This seems to me to be a classic race condition, since the message box is blocking the JS thread, which changes what order the threads get executed. Since the message is stuck on the screen, I'm guessing that the UI thread was blocking the out of JS thread data access from completing and populating the grid. By putting in the message box I am yielding access to other threads: the http responses. Am I correct? (I know JS is technically really single threaded. I am using the word 'thread' in a conceptual sense, how things look from outside the black box)

That's my guess. But I am not sure what I can do about it. In my opinion this kind of stuff should never happen in a high level library, since I have no access to the inside of the code to debug it. The library should handle synchronization or generate an error if it can't. If it finds a resource in an inconsistent state, it should throw an exception. It should not just hang.

My question:
What is actually changed deep inside by putting that SC.say() in? Because that 'fixed' the problem. Any suggestion or idea would be greatly appreciated.

-kornel

[Isomorphic]

Unlike the native JavaScript alert(), SC.say() does not block execution or change execution order.

The first thing to do when something appears to freeze is to run in compiled mode and see if there is diagnostic information and/or a stack trace (see FAQ for instructions). This will begin to eliminate causes, one being possible bugs in core GWT (not SmartGWT).

[kcsaszar@anstca.com]

The whole issue just got even stranger...

I deployed into the server. No errors were put in the log. I also looked with the SC console. Again no messages were reported.

Then I tried something that should have not made a difference at all, but one never knows:
I took out the SC.say(). So now I have only an empty DataArrivedHandler like this:

grid.addDataArrivedHandler(new DataArrivedHandler() {
public void DataArrivedEvent event) {
}
});

And this by itself solved the problem. Now the IDA call returns, the grid is populated and the "Contacting Server..." disappears. This makes no sense to me.

Also I was hoping that you would at least check the library code for possible causes rather just bouncing back the ball to us without any suggestions as to what might have gone wrong.

For instance I am aware of one similar condition which causes server calls not to return. The RPCs are cached by Google which sometimes gets out of synch with the Java code. So far every time something like this happened, deleting the RPC directory solved the problem. But not this time.

I was hoping that, as a support person, you would have heard of other likely causes of this behavior. If even I know of one possible cause, you must surely have heard of more of them... Maybe you could ask your colleagues. We are paying for support...

[Isomorphic]

We have no similar reports despite pervasive usage of this API in virtually all applications. That's why we had you look for a JS error.

The next thing we'd recommend is upgrading GWT. That's a really, really old version and stands out as a unique factor that could explain why only you have this problem.

If that doesn't immediately fix it, take some other basic steps:

1. make sure you can replicate it on another developer's machine

2. clarify whether this is browser-specific *in compiled mode*

3. if you have any plugins or non-default settings in IE8, test with those reverted

[kcsaszar@anstca.com]

Unfortunately an upgrade is not possible right now, since that would be a major project. I know it's not supposed be, but something always goes wrong, especially since we are so far behind. And we have quite a bit of code.

But the good news is that leaving the empty DataArrivedHandler seems to work as a workaround.

Thanks for the additional suggestions though. I'll look at those if the error starts re-occuring.

-kornel

[Isomorphic]

Glad you have a workaround.
If you do find you need to pursue this further, we'd recommend you try to take the steps we suggested on some test configuration even if an upgrade isn't immediately possible for your public deployment. This would allow you to identify (or rule out) whether it is indeed a version specific issue or something else

Regards
Isomorphic Software