Atmosphere JQuery plugin: response read in multiple chunks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Atmosphere JQuery plugin: response read in multiple chunks

Koen Serneels-2
I'm using  atmosphere with the JQuery atmosphere plugin to create a long polling request to a json returning service via jersey.
The client JS I copied from an example somwhere I changed it to my needs:

function callback(response) {.......
}

var location = "ImageService/upload";
$.atmosphere.subscribe(location, !callbackAdded ? callback : null, $.atmosphere.request = { transport: "long-polling" });

One of the problems I'm facing is that when the response is received, my callback is called multiple times with each time a new chunk of the response.
The chunk history is also there; so it looks like the response object 'grows' by adding each time a new chunk of response data to it.
So only after the last chunk has been added the response will be complete for processing (in my case the callback has then already 43 times been called).

The problem is that i cannot determine on a cheap way WHEN my response is complete.
Right now I'm parsing the response to a JSON object, and doing nothing if that fails (so when the response is complete, the parsing will succeed).
This is however pretty time consuming and  not very defensice: supose my response is actually complete but there is a problem in the JSON format?
Another solution is adding a token to indicate the end, but that is not always possible when the service is not under my control.

I did notice that there is no content length header in my response, this is probably a jersey issue.
So I tried  adding a content-length header manually in the response.
I could see that the CL header is taken into account: if I make the CL size smaller then the actual payload size I can see that a part of the response is not read.
However, this did not change anything about the chunk reading: the part that was read from the response was still read in chunks. So a CL header changes nothing in this respect.

My question: is it possible to configure this so the response is read in one time?
Or at least, if it is read in multiple chunks, is there a way to cheaply find out when the response is complete and I can start processing it?

PS. I tested this on FF 3.6.18 and on IE8. Both gave the same result.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atmosphere JQuery plugin: response read in multiple chunks

ghillert
Hi Koen,

Can you verify whether it works in Chrome? Interestingly I was hitting the opposite issue that for multiple responses I would get one callback only:


Interestingly, the problem seems to have gone away for me. Do you have the JavascriptClientFilter setup in web.xml?

       <init-param>
           <param-name>org.atmosphere.cpr.broadcastFilterClasses</param-name>
           <param-value>org.atmosphere.client.JavascriptClientFilter</param-value>
       </init-param>

Cheers,

Gunnar

On Sun, Jul 24, 2011 at 9:45 AM, Koen Serneels <[hidden email]> wrote:
I'm using  atmosphere with the JQuery atmosphere plugin to create a long polling request to a json returning service via jersey.
The client JS I copied from an example somwhere I changed it to my needs:

function callback(response) {.......
}

var location = "ImageService/upload";
$.atmosphere.subscribe(location, !callbackAdded ? callback : null, $.atmosphere.request = { transport: "long-polling" });

One of the problems I'm facing is that when the response is received, my callback is called multiple times with each time a new chunk of the response.
The chunk history is also there; so it looks like the response object 'grows' by adding each time a new chunk of response data to it.
So only after the last chunk has been added the response will be complete for processing (in my case the callback has then already 43 times been called).

The problem is that i cannot determine on a cheap way WHEN my response is complete.
Right now I'm parsing the response to a JSON object, and doing nothing if that fails (so when the response is complete, the parsing will succeed).
This is however pretty time consuming and  not very defensice: supose my response is actually complete but there is a problem in the JSON format?
Another solution is adding a token to indicate the end, but that is not always possible when the service is not under my control.

I did notice that there is no content length header in my response, this is probably a jersey issue.
So I tried  adding a content-length header manually in the response.
I could see that the CL header is taken into account: if I make the CL size smaller then the actual payload size I can see that a part of the response is not read.
However, this did not change anything about the chunk reading: the part that was read from the response was still read in chunks. So a CL header changes nothing in this respect.

My question: is it possible to configure this so the response is read in one time?
Or at least, if it is read in multiple chunks, is there a way to cheaply find out when the response is complete and I can start processing it?

PS. I tested this on FF 3.6.18 and on IE8. Both gave the same result.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atmosphere JQuery plugin: response read in multiple chunks

Koen Serneels
Ghillert,

Just to be sure; I only have one response. I serialize a Java POJO to JSON which is then added to the http response. The http response body looks like this: {"data":"blabla","filePath":"/some/path/file.jpeg"}
The "blabla" part is rather big, its a base64 encoded string of an ~100kb image.

I re-tested this and the conclusion is as follows.
The response size was eventually always 158080 bytes:

On FF/Ubuntu: Long polling - callback is called variably, between 40-50 times
On FF/Windows: Streaming - callback is called variably, between 40-50 times
On Chrome/Windows: Streaming - callback is called variably, between 10-20 times
On IE8/Windows: Streaming - callback is called 1 time

I have to say that on IE8 my image was not shown. Sometimes it did but only partially (on all other browsers it show up ok).
I think that this has to do with the amount of base64 data a browser can handle for an inline image.
The data was however fully received, so the fact that it is not shown is beyond the scope of this problem.

The following things are weird:

- Why is the callback called multipke times on all browsers besides IE?
- Why is the amount of callbacks variably on a single browser? There was also no real 'trend' to be seen. One time its 45 times, next its 41, then its 47, etc..
- Even more weird is that when I choose long-polling (which should be the most browser compatible way of doing comet) it is using streaming on windows? It appears to deal with that transparantly, as the next time data is received the response buffer is 'cleared' again. I'm saying this because I tested with streaming explicitly on FF/ubuntu before. Back then I saw that the response kept on growing. So when I sended a second image, the first image still appeared in the response (I don't know if that would also be the case on windows, I don't even know if this is suposed to be like that with streaming?).

This is how a response on ubuntu looks like:

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Expires: -1

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Access-Control-Allow-Origin: *

Content-Type: application/json

Date: Sat, 30 Jul 2011 10:06:15 GMT

Connection: close



{"data":"/9j/4AAQSkZJRgA....blabla....", filePath":"/some/path/file.jpeg"}

This is how it looks when issues from a browser on windows (ie, ff, chrome, all the same):

Server: Apache-Coyote/1.1

Expires: -1

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Access-Control-Allow-Origin: *

Content-Type: application/json

Transfer-Encoding: chunked

Date: Sat, 30 Jul 2011 09:24:43 GMT



2000

{"data":"/9j/4AAQSkZJRgA....
/.......

2000

.....
9ba
......

+Hr//Z","filePath":"/some/path/file.jpeg"}

0

So you might think it is because it is 'chunked' on windows that both chrome and FF do the callback multiple times. However, IE also gets the 'chunked' response and shows it in one time.
Also, on ubuntu the response comes in as a whole, as you can see. And there the callback is also called multiple times.

Is there anyone that can shed some light on this?

PS. I tried your init-param, for me it didn't change anything.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atmosphere JQuery plugin: response read in multiple chunks

Jeanfrancois Arcand-4
Salut,

can you try the latest version (0.8-SNAPSHOT) and see if that helps?

Thanks

-- Jeanfrancois

On 11-07-30 6:52 AM, Koen Serneels wrote:

> Ghillert,
>
> Just to be sure; I only have one response. I serialize a Java POJO to JSON
> which is then added to the http response. The http response body looks like
> this: {"data":"blabla","filePath":"/some/path/file.jpeg"}
> The "blabla" part is rather big, its a base64 encoded string of an ~100kb
> image.
>
> I re-tested this and the conclusion is as follows.
> The response size was eventually always 158080 bytes:
>
> On FF/Ubuntu: Long polling - callback is called variably, between 40-50
> times
> On FF/Windows: Streaming - callback is called variably, between 40-50 times
> On Chrome/Windows: Streaming - callback is called variably, between 10-20
> times
> On IE8/Windows: Streaming - callback is called 1 time
>
> I have to say that on IE8 my image was not shown. Sometimes it did but only
> partially (on all other browsers it show up ok).
> I think that this has to do with the amount of base64 data a browser can
> handle for an inline image.
> The data was however fully received, so the fact that it is not shown is
> beyond the scope of this problem.
>
> The following things are weird:
>
> - Why is the callback called multipke times on all browsers besides IE?
> - Why is the amount of callbacks variably on a single browser? There was
> also no real 'trend' to be seen. One time its 45 times, next its 41, then
> its 47, etc..
> - Even more weird is that when I choose long-polling (which should be the
> most browser compatible way of doing comet) it is using streaming on
> windows? It appears to deal with that transparantly, as the next time data
> is received the response buffer is 'cleared' again. I'm saying this because
> I tested with streaming explicitly on FF/ubuntu before. Back then I saw that
> the response kept on growing. So when I sended a second image, the first
> image still appeared in the response (I don't know if that would also be the
> case on windows, I don't even know if this is suposed to be like that with
> streaming?).
>
> This is how a response on ubuntu looks like:
>
> HTTP/1.1 200 OK
>
> Server: Apache-Coyote/1.1
>
> Expires: -1
>
> Cache-Control: no-store, no-cache, must-revalidate
>
> Pragma: no-cache
>
> Access-Control-Allow-Origin: *
>
> Content-Type: application/json
>
> Date: Sat, 30 Jul 2011 10:06:15 GMT
>
> Connection: close
>
>
>
> {"data":"/9j/4AAQSkZJRgA....blabla....", filePath":"/some/path/file.jpeg"}
>
> This is how it looks when issues from a browser on windows (ie, ff, chrome,
> all the same):
>
> Server: Apache-Coyote/1.1
>
> Expires: -1
>
> Cache-Control: no-store, no-cache, must-revalidate
>
> Pragma: no-cache
>
> Access-Control-Allow-Origin: *
>
> Content-Type: application/json
>
> Transfer-Encoding: chunked
>
> Date: Sat, 30 Jul 2011 09:24:43 GMT
>
>
>
> 2000
>
> {"data":"/9j/4AAQSkZJRgA....
> /.......
>
> 2000
>
> .....
> 9ba
> ......
>
> +Hr//Z","filePath":"/some/path/file.jpeg"}
>
> 0
>
> So you might think it is because it is 'chunked' on windows that both chrome
> and FF do the callback multiple times. However, IE also gets the 'chunked'
> response and shows it in one time.
> Also, on ubuntu the response comes in as a whole, as you can see. And there
> the callback is also called multiple times.
>
> Is there anyone that can shed some light on this?
>
> PS. I tried your init-param, for me it didn't change anything.
>
> --
> View this message in context: http://atmosphere-users-mailling-list.2493822.n2.nabble.com/Atmosphere-JQuery-plugin-response-read-in-multiple-chunks-tp6615234p6636000.html
> Sent from the Atmosphere users mailling list mailing list archive at Nabble.com.
>
Loading...