Comet/server-push problem in IE, extending VView

Hello,

I’ve implemented a Comet/Server side push solution for Vaadin and I have two issues with it.

The solution does not seem to work properly in IE. Although comet requests are done correctly and notifications from server to client are delivered, the request created by ApplicationConnection.sendPendingVariableChanges() hangs as IE reports error: -2146827286 with message:

(SyntaxError): Syntax error number: -2146827286 description: Syntax error - Original JSON-text:

There is no text after “Original JSON-text” in the message window.

My second issue - I’ve tried to implement it as an extension to Window/VWindow functionality, but the root window is rendered as VView on the client side. Is there any way I could add some data to the UIDL stream and process them without having to modify Vaadin’s source code?

As a side node, I found ICEpush component not enough for me - it was locking server threads, in this case Apache Tomcat’s, which is not acceptable. At first I tried to use base ICEpush library by myself, but I found it overcomplicated for a Vaadin application.

Nice! Do you plan to share it in the Directory?

Have you tried using GWT Development mode to debug it? Or Fiddler or some other IE plugin to look at the network traffic? The message comes from ApplicationConnection when it fails to parse the JSON response from the server and for some weird reason it does not seem to include the JSON text even though it says "Original JSON-text: " (Created #5333). The original JSON text is however logged to the debug console.

VWindow is used only for sub windows and VView is used for browser level windows. Both are currently represented as Window on the server side. VView is a special case that you cannot override using annotations.

Extending Window on server side and adding some data to the UIDL (only for browser level windows) is an option but then you need to either update VView or add a GWT replacement rule in your widgetset.gwt.xml file so you can use your own VView implementation. Something like this might work:

	<replace-with class="com.example.myView">
		<when-type-is class="com.vaadin.terminal.gwt.client.ui.VView" />
	</replace-with>

Most probably, but I would rather share it when it will be ready for a production environment.

I couldn’t find it in debug console either, but after I checked it, there’s no actual response - the request hangs and does not receive any data.

I’m almost sure I’m doing something wrong with connection management, and IE reaches its connection limit, blocking Vaadin requests. As the HTTP 1.1 specification allows only two simultaneous connections I aimed for using only one (or none, when not needed) for comet. That would explain why it does not work at all in IE using GWT Development mode, as it establishes additional connection with the code server.

It does work with other major browsers (Firefox, Opera, Safari and Chrome, to be exact) - they probably have their connection limit set to higher than 2. For Firefox it works like a charm both in normal mode and GWT Dev mode.

I will most certainly look into it. Can I extend VView in my replacement class to avoid boilerplatte code, or would GWT treat it as cyclic reference?

I wonder if it’s possible for me to send UIDL changeset in the Comet response payload and invoke updating on the client side. That would have several benefits:

  • only one request-response pair required to update GUI with server-side changes
  • allows seamless integration, as proper window implementation could constantly send comet requests and be notified immediately about server-side changes, without programmers having to invoke “push” methods of any kind, thus without them having to be aware of any comet mechanism at all
  • personally I think it would be awesome :wink: it could be a solution to the
    #1 user voice request

I couldn’t get replacement rule to work. I’ve tried it both with VView and more regular component - VButton. Code in the replacement class was never executed.

Hi!

This is definitely how things should work. I guess it needs a custom servlet and CommunicationManager though. If you are interested in diving into that area, I’m happy to help you.

The VView should be overrideable with deferred binding in tomorrows nightly. I changed its initialization so that it now has a constructor without parameters (making it compatible with GWT.create()) and an init method, that does pretty much everything that was previously done in constructor.

cheers,
matti

I wonder if it is possible to create implementation of CommunicationManager along with Request/Response interfaces (inners of com.vaadin.terminal.gwt.server.AbstractCommunicationManager) which would provide necessary data for the Request/Response objects, for example output stream that would write to the comet response payload. Yet I’m afraid I’m not familiar enough with Vaadin’s source to achieve this - any help would be appreciated.

On the client side, how should such response be handled to perform all the necessary operations?

I’ll look into it as soon as new nightly will be available. Replacing VView would be the best solution, as a Window instance is needed anyway for the CommunicationManager on the server side.

I will still have a problem though - instead of extending VView I’ll have to copy it’s code into replacement class. Subclassing would clearly lead to an infinite invocation loop - tried it with replacing VButton class and showing an alert window from replacement class constructor :wink: