trying to understand unresponsive script waiting on UIDL call

[Michael (Michael Grove)]

I’m seeing my vaadin application when used in embedded mode via Vaadin-xs occasionally lock up due to an unresponsive script. This happens most frequently in Chrome 10 on OSX, but I’m able to reproduce in FF3 and Safari 5, albeit less frequently.

This is the error message that is printed by Firefox:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://localhost:8080/pelorus-web2/UIDL?windowName=1&1300903510065&payload=9b443995-1f66-4504-9e49-c193ea1f6384-----BEGIN+PGP+MESSAGE----- Version%3A+haneWIN+JavascriptPG+v2.0 hEwDAAAAAAAAAAABAf9nObF%2BD48Q8MzQqHp4NcL3rCAIgYf4z%2BLJodHyAJbv %2FVWXJjqF0hqvG5xB2E5p%2B6d4ydJyDm56qi2GS5oQVHVNpGikTVBrMfP%2B1Ort ntw5BB%2F09s68Z8%2BaJUb55TRbE468JD3isX8cqzmjxxoJ0od%2BLpsJZOtNs7ve L2WlR35Gt6pDvbS8zPSM%2BRabl1L%2FSmYSrQ2e4bsTH69pdmI0qNS0h3FieGIN MWDjNA%3D%3D %3Duga2 -----END+PGP+MESSAGE----- &callback=__gwt_jsonp__.I1.onSuccess:1

I put in some debug statements into XSApplicationServlet and JsonpCommunicationManager and I noticed this oddity. Normally, a UIDL request looks like this:

service: /UIDL
Calling super.service: UIDL
writeUiDLResponse
end.writeUiDLResponse
Done super, out: UIDL

What I’m seeing when it locks up is:

service: /UIDL
Calling super.service: UIDL
Done super, out: UIDL

So the calls to writeUIDLResponse in JsonpCommunicationManager never occur. Is there a reason why that method would not be called under normal usage?

Thanks.

Michael

[Matti (Matti Tahvonen)]

Debugging jsonp style communication sucks, I know. This is even worse due the fact that GWT doesn’t support debugger with xs linker.

Firebug (both debugger and resource panel), pretty compiled client side and server side debugging are the hints I can provide. Some kind of remote debugger via Vaadin forum would be great. Maybe they can build it for the next version

Oh… I forgot. VConsole.log() style client side logging and ?debug=q request parameter might help on the client side.

__
cheers,
matti

[san (san seven)]

it’s usefull

[Michael (Michael Grove)]

@Matti Tahvonen

Debugging jsonp style communication sucks, I know. This is even worse due the fact that GWT doesn’t support debugger with xs linker.

Firebug (both debugger and resource panel), pretty compiled client side and server side debugging are the hints I can provide. Some kind of remote debugger via Vaadin forum would be great. Maybe they can build it for the next version

Oh… I forgot. VConsole.log() style client side logging and ?debug=q request parameter might help on the client side.

Yes, the debug console is normally useful, but it does not display in embedded mode, and since the bug only happens in embedded mode, I was stuck resorting to System.err.println statements.

The problem is the referrer URL tracking is incorrect in XSApplicationServlet and an exception is thrown and presumably not caught, so the response is never sent back to the client, and thus the browser waits forever for the request to come back and hangs.

This is a server side error, usually for these you get the big red box of death letting you know there was an error on the server, or the inline ‘!’ icon which shows the stacktrace, neither of these happens, so I assume the exception is handled outside of the normal channels.

[Matti (Matti Tahvonen)]

@Michael Howard Grove

This is a server side error, usually for these you get the big red box of death letting you know there was an error on the server, or the inline ‘!’ icon which shows the stacktrace, neither of these happens, so I assume the exception is handled outside of the normal channels.

Hi,

This issue is fixed along with trunk and vaadin 6.5.4.

cheers,
matti