Web client reliability

Classic Servoy
1

All…

We’ve had a number of cases lately where UI updates are sometimes not showing in the browser. Instead, the application appears unresponsive. This appears random but we did finally uncover at least one explanation as we were attempting to demo our Servoy-based application at a conference and had it appear to hang many times. While running one of our other applications we were getting errors and realized it was because of connections being dropped due to the Internet connection at the conference being over-utilized. The problem seems to be that the Servoy web-client isn’t resilient in the face of connections being dropped (understandable) but much worse is that there is no indication to the user when a connection has failed. I did some investigation by viewing the source of the HTML in my browser to see if this is actually the case and it appears that this is true.

Here’s an example snippet of Javascript re-formatted for readability:

if (testDoubleClickId('sv_50e29be9_1e7e_4a10_bdb8_d98dd3e38242')) 
{ 
  wicketShow('indicator');
  var wcall=wicketAjaxGet('?x=OFvjI5lD6SuXygmFaTppRtCAtz4mf6pz',
   function(){;wicketHide('indicator');}.bind(this),
   function() { ;wicketHide('indicator');}.bind(this), 
   function() {return Wicket.$('sv_50e29be9_1e7e_4a10_bdb8_d98dd3e38242') != null;}.bind(this));
} 
return false;

This bit of code is attached as an event handler on some HTML but that’s not the important bit. The important thing is the wicketAjaxGet() call. I examined the Javascript file that contains this method and here are the method parameters for that call:

function wicketAjaxGet(url, successHandler, failureHandler, precondition, channel) 
{ ... }

As you can see this method supports passing in a failureHandler which appears to be exactly what we’d want to register in order to notify the user that a connection has failed but if you look back to the first code snippet you’ll see that the third-parameter passed into the method is identical to the second parameter which appears to simply hide the busy indicator. In other words, in this particular case success and failure of this connection is handled identically with no indication given to the user that the connection failed. While the snippet above is only one example I looked through the whole page and didn’t see a single instance where it looked like an error handler was being registered as a callback.

Am I missing something here? This seems to explain why we experience an unresponsive interface at times without any indication given to the user of what’s gone wrong. Is there a setting or something that we aren’t setting to enable error handling? Are we the only ones that are experiencing random “hangs” in the browser (fixed, at least temporarily by re-loading)?

If my premise is correct can Servoy please resolve this situation? This is absolutely critical for us as we’ve had a number of demos lately that were failures potentially tied to this issue. Right now our confidence going into a demo is very low. :(

Our server is currently running v4.1.0 beta 3.

Thanks!
Corey

2

we will add better support for handling those errors like pop up a div that let the user know that the current action didnt go through.

but do you get a lot of these errors? because these kind of things should only really happen if your connection is broken to the server. Does that happen a lot when you are demoing?

3

Johan,

Thanks for responding. Will this error handling make it into v4.1.0?

I wouldn’t say we get it happening a lot. It’s just that it happened to us twice at very inopportune times. Unfortunately, without feedback in the browser it looks like the application itself is very unstable. If a dialog pops up indicating a connection problem then we can at least point to that as being the issue rather than the application itself.

I guess another question is how does the web client respond when the server encounters an error in responding to the request (it could be a database error for example)? Does the server send back an error code of some kind that can then be displayed by the client?

Initially, we’d be happy at least to just have an error pop up on connection failure but we’re going to want some way of having the client respond to other server-side errors as well. (Perhaps this is already possible – I’m pretty new to Servoy.)

Thanks again,
Corey

4

those database errors have to be handled by the servoy developer
just catch those exceptions in the solution error handler and show something in your form (or show a form in dialog)

5

jcompagner:
those database errors have to be handled by the servoy developer
just catch those exceptions in the solution error handler and show something in your form (or show a form in dialog)

Thanks for that.

Can you confirm whether the error notification on network errors will be in the next beta release?

Thanks,
Corey

6

no cant confirm this yet. We are busy with it and we have to see which version we can drop that in.