Re: First server-side event detected, the rest are lost.

[Donghwan Kim]

Hi Brad,

The code you posted is not sufficient to solve the problem. I think the response text may be formatted wrongly.

As I told you, when the sse transport is used, the normal response text looks like 

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Atmosphere-tracking-id: 120c8b0f-b7ba-48d5-b9d5-f40d8e6c53c0
Expires: -1
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Content-Type: text/event-stream;charset=utf-8
Date: Wed, 22 May 2013 07:35:18 GMT
Content-Length: 2310

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
data: {"id":1,"type":"message","data":{"username":"Donghwan","message":"Hi Brad"},"reply":false}

data: {"id":2,"type":"message","data":{"username":"Donghwan","message":"How are you"},"reply":false}

data: {"id":3,"type":"heartbeat","data":null,"reply":false}

I have never used the libevent server, but it would be helpful if you would post the server side code as well as the plain response text in question like the above one. Also, first you can test that the connection following the server-sent events spec works correctly by using plain the EventSource object instead of using the portal. The portal use such a connection transparently. To do this, see http://www.html5rocks.com/en/tutorials/eventsource/basics/

Note that the portal uses only the message event in the spec as message event in portal.

Thanks,

-- Donghwan

On Thu, May 23, 2013 at 3:49 PM, Brad Emke <pacc...@yahoo.ca> wrote:

Greetings. My goal is to create a webapp that can be continually updated with data from a libevent-based server. The server uses chunk-transfer encoding, sending new data once per second. The simple test client has the code shown below. The streaming connection is created first (with the code below), then a JQuery post function is invoked to send a request to the server asking for a particular type of data. The server acknowledges the post request (the success handler sees the response), and, one second later, sends the first data item across the streaming connection. This first piece of data is detected by the "message" handler. Unfortunately, none of the subsequent data items trigger the "message" handler. To rule out the possibility that subsequent items were corrupt, I altered the server such that the same item is sent every time, but the behaviour is unchanged: the first item is detected, but none of the later items are seen. I've tried removing the server's acknowledgment of the post(), but that does not help. The "close" handler does not execute until the server is terminated, so the connection seems to survive.

Any idea?


   $(function()
   {
      var transports = [ "sse" ];

      portal.open("/blah", {transports: transports, timeout: false, heartbeat: false})
      .on({
         connecting: function()
         {
            console.log("Connecting with the transport [" + transports + "] (" + this.data("transport") + ").");
         },
         open: function()
         {
            console.log("Opened at " + portal.support.now());
         },
         message: function(data)
         {
            console.log("In message?");
         },
         close: function(reason)
         {
            console.log("Closed by the reason [" + reason + "]");
         }
      });

...

--
You received this message because you are subscribed to the Google Groups "Portal" group.
To unsubscribe from this group and stop receiving emails from it, send an email to portal_projec...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brad Emke]

Thank you for your reply. I believe I have found the problem. When I transitioned the server to sse from streamxhr, I did not remove the first event, which was a 1 kilobyte response. I eventually found the existence of this first event using fiddler. (Thanks for the link to it.) Curiously, the first actual event (sent 1 second after the 1 kilobyte response) is seen by the client--I would have thought this would have been ignored like all the later events. When I removed the legacy code that was sending the first event, all of the events were recognized by the client.

The only header that seems to be required, at least on my Firefox instance, is Content-Type, and that must be set to a value that includes text/event-stream. Note that the content length is embedded in the body of the response, not set in the headers, when chunked transfers are used.

Thanks again for the advice.
Brad.