Thanks for the response.
> Another solution: make your RPC calls only "accept" (in the sense of
> the 202 HTTP status code) the request and send the response back into
> the "comet feed". That way, your RPC calls would be very fast (the
> server answers without any processing) and could be queued up into the
> one connexion left usable without slowing the application that much.
> ...but this means making your own generators for GWT-RPC services or
> changing your application architecture (well, if you have DAOs, only
> this layer would have to be changed ideally...)
ah, this is the best answer, i think, but not worth the HUGE amount of
time necessary to implement.
should have thought of it to start with.
> If you have to make many other requests, use the heartbeat solution
> (or a mix of both ideas: with timeouts so that your long-standing
> requests won't block other RPC calls for too long)
frequent timeouts is a great idea, and works pretty well.
i am working on killing the comet inside of the first of multiple rpc
calls.
thanks again!
On Sep 4, 6:42 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> On 4 sep, 08:51,elliot<[EMAIL PROTECTED]> wrote:
>
> > holding the cnxn open is SUCH a cool idea, Folke! {and kilkenny, who i
> > notice just posted useful links}
> > whoever thought of that is a crafty person to trick http like that.
>
> > however, it slows me down considerably, presumably because of the
> > large number of other rpc calls my app makes {in parallel}.
> > i hate the 2 call per server limit- maybe i can make a separate
> > realtime server?
>
> SOP will stop you.
>
> If you have to make many other requests, use the heartbeat solution
> (or a mix of both ideas: with timeouts so that your long-standing
> requests won't block other RPC calls for too long)
>
> Eventually, you could manage your own request queue, and automatically
> cancel() your pending "comet" request when you need to use the "second
> connexion".
> ...but keep in mind that IE8 brings up the limit to 6 connexions per
> server ;-)
>
> Another solution: make your RPC calls only "accept" (in the sense of
> the 202 HTTP status code) the request and send the response back into
> the "comet feed". That way, your RPC calls would be very fast (the
> server answers without any processing) and could be queued up into the
> one connexion left usable without slowing the application that much.
> ...but this means making your own generators for GWT-RPC services or
> changing your application architecture (well, if you have DAOs, only
> this layer would have to be changed ideally...)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
