RE: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-09 Thread Peter Farland
The maximum number of concurrent HTTP connections allowed to a web
server is controlled by the browser. The HTTP 1.1 specification suggests
a limit of 2 connections per host, but this requires further
consideration if persistent connections are to be used. Some browsers
can be configured to accept more, but your users will more than likely
have the default settings. IE honors the 2 connections per host
suggestion (but to change this you have to edit the registry, see
MaxConnectionsPerServer). Firefox sets this value to 8 but does still
limit persistent connections to 2 (you can change these settings via
about:config).
 
If you were dealing with a closed network or intranet application, you
may be able to change your company's IT policy and roll out different
default settings, but for public applications I doubt this will be
possible. There are lots of other tricks that you can use to optimize
HTTP requests (e.g. idempotent GET requests you benefit from pipelining
etc)... but my point is that there's a bit more to consider than a bunch
of simultaneous requests.


Re: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-09 Thread dorkie dork from dorktown

So what you are saying is if I have 3 httpservice requests send at the same
time 2 go out and 1 is queued up. When a result or fault event occurs on one
of them then the 3rd service request is sent correct?

How do I know if I am using a persistent connection? I was asking this
question earlier, does a Flex application keep the connection alive so that
sessions will never timeout as long as the application is running in the
browser? Even if the user has is not sending any requests to the server but
the first? Sorry don't mean to hijack this thread.



On 09 Apr 2007 05:20:37 -0700, Peter Farland [EMAIL PROTECTED] wrote:


   The maximum number of concurrent HTTP connections allowed to a web
server is controlled by the browser. The HTTP 1.1 specification suggests a
limit of 2 connections per host, but this requires further consideration if
persistent connections are to be used. Some browsers can be configured to
accept more, but your users will more than likely have the default settings.
IE honors the 2 connections per host suggestion (but to change this you have
to edit the registry, see MaxConnectionsPerServer). Firefox sets this value
to 8 but does still limit persistent connections to 2 (you can change these
settings via about:config).

If you were dealing with a closed network or intranet application, you may
be able to change your company's IT policy and roll out different default
settings, but for public applications I doubt this will be possible. There
are lots of other tricks that you can use to optimize HTTP requests (e.g.
idempotent GET requests you benefit from pipelining etc)... but my point is
that there's a bit more to consider than a bunch of simultaneous requests.

 



RE: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-09 Thread Peter Farland
I believe that yes, once one of the previous requests completes (either
by a fault or result) the next outstanding request can proceed. Note
that you can make use of multiple CNAMEs to increase the number of
requests made concurrently per host (e.g. Google Maps uses
mt0.google.com through mt3.google.com to get 8 concurrent connections to
load map data).
 
Persistent / reusable / keep alive connections are the default
behavior for HTTP 1.1 your connections are being re-used for multiple
requests already. The period for a persistent connection however is
typically much smaller than, say, the life of a J2EE session. Keep alive
is merely a hack to optimize the situation when multiple requests are
made to the same host in a short period of time. If you had a UI that
was comprised of 25 individual assets then you wouldn't want to
re-establish 25 connections and perform the usual HTTP handshake for
each request (and it would be even worse for HTTPS based connections).
HTTP that makes use of keep alive should still be considered a
stateless situation.
 
A completely different approach for persistent connections is the
style used by COMET servers and chunked encoding. Here the client
immediately establishes a connection to the server on receiving data and
the server holds on to the connection until new data is available to
push back to the client. This does, however, impact on the number of
simultaneous connections that a server can handle because it ties up
threads on the server. 


Re: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-08 Thread Ray Horn
I too ran into this sort of problem however I chose to build a REST 
Serialization mechanism that guarantees I can queue-up requests as deep as I 
need and then execute them serially since that is the way my REST backend needs 
the requests in order to maintain database state.


- Original Message 
From: coderdude2 [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Saturday, April 7, 2007 5:05:02 PM
Subject: [flexcoders] Sending multiple HTTPService requests - how to really 
cancel all but the last

I'm using several HTTPService calls to plain old REST API's on the
backend.

If the end user clicks some of the UI controls multiple times quickly,
many calls to these services get queued up, and it can take a long
time for all the data to be retrieved.

For ex. clicking on a list box item sends requests to refresh all the
data, and if the user were to use the keyboard to quickly scroll
through the listbox, many many calls would get queued up.

I've tried setting the concurrency= last on the httpservices, but it
appears the only effect of that is to make the UI change only when the
last dataset is received, but still all the service calls continue to
be queued and there is a long delay after making many calls.

I've also tried httpservice .disconnect( ) and .cancel() before making
any new backend call but it didn't appear to have any effect as far as
preventing many calls from getting queued up.

Thanks in advance for any ideas. I know I could also look into
retrieving all the data only once and doing local Flex filtering on it
rather than getting the data fresh from the backend each time, but for
now it's just easier to make the backend calls and use the DB to do
the proper filtering and querying.




Re: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-08 Thread dorkie dork from dorktown

arent httpservice requests asyncronous? i thought you could have a bunch
running at the same time and receive a response from each as you got them.
are they returning in linear order? in an application i'm working on i make
three different service request calls. i'll see if i can find out how to
cancel them.

On 07 Apr 2007 23:48:50 -0700, Ray Horn [EMAIL PROTECTED] wrote:


  I too ran into this sort of problem however I chose to build a REST
Serialization mechanism that guarantees I can queue-up requests as deep as I
need and then execute them serially since that is the way my REST backend
needs the requests in order to maintain database state.

- Original Message 
From: coderdude2 [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Saturday, April 7, 2007 5:05:02 PM
Subject: [flexcoders] Sending multiple HTTPService requests - how to
really cancel all but the last

 I'm using several HTTPService calls to plain old REST API's on the
backend.

If the end user clicks some of the UI controls multiple times quickly,
many calls to these services get queued up, and it can take a long
time for all the data to be retrieved.

For ex. clicking on a list box item sends requests to refresh all the
data, and if the user were to use the keyboard to quickly scroll
through the listbox, many many calls would get queued up.

I've tried setting the concurrency= last on the httpservices, but it
appears the only effect of that is to make the UI change only when the
last dataset is received, but still all the service calls continue to
be queued and there is a long delay after making many calls.

I've also tried httpservice .disconnect( ) and .cancel() before making
any new backend call but it didn't appear to have any effect as far as
preventing many calls from getting queued up.

Thanks in advance for any ideas. I know I could also look into
retrieving all the data only once and doing local Flex filtering on it
rather than getting the data fresh from the backend each time, but for
now it's just easier to make the backend calls and use the DB to do
the proper filtering and querying.


 



Re: [flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-08 Thread Ray Horn
Yes, HTTPService requests can be operated in async mode but what happens if the 
state of your database requires serialization of requests or what happens if 
you need to debug your server-side code and you are doing this through the use 
of some kind of log file - async server requests can make debugging a problem 
even if you have some kind of debugging system that lets you step through your 
server side code.  I think if you think about this you might come to the same 
conclusion I did.

Also I found that my async HTTPService requests were failing sometimes for odd 
reasons until I chose to run them serially one after another through a single 
HTTPService Object.

Since I have a lot of experience coding AJAX based systems it was very easy for 
me to adapt to the apparent problems I was seeing and rather than bank on the 
code working when it appeared to be failing I chose to run my requests one 
after another to facilitate debugging and maintain my database state.

Keep in mind when requests are being run async it may be possible for a 
subsequent request to be run out of order, in case it matters what order the 
requests need to be run in.

Maybe your async HTTPService Requests may not run into the same problems mine 
did or maybe yours are simpler than mine are but this is what I did to ensure 
mine would work.


- Original Message 
From: dorkie dork from dorktown [EMAIL PROTECTED]
To: flexcoders@yahoogroups.com
Sent: Sunday, April 8, 2007 7:25:08 AM
Subject: Re: [flexcoders] Sending multiple HTTPService requests - how to really 
cancel all but the last

arent httpservice requests asyncronous? i thought you could have a bunch 
running at the same time and receive a response from each as you got them. are 
they returning in linear order? in an application i'm working on i make three 
different service request calls. i'll see if i can find out how to cancel them. 


On 07 Apr 2007 23:48:50 -0700, Ray Horn [EMAIL PROTECTED] net wrote:
I too ran into this sort of problem however I chose to build a REST 
Serialization mechanism that guarantees I can queue-up requests as deep as I 
need and then execute them serially since that is the way my REST backend needs 
the requests in order to maintain database state. 



- Original Message 
From: coderdude2 [EMAIL PROTECTED] com 
To: flexcoders@yahoogroups.com
Sent: Saturday, April 7, 2007 5:05:02 PM
Subject: [flexcoders] Sending multiple HTTPService requests - how to really 
cancel all but the last 


I'm using several HTTPService calls to plain old REST API's on the
backend.

If the end user clicks some of the UI controls multiple times quickly,
many calls to these services get queued up, and it can take a long 
time for all the data to be retrieved.

For ex. clicking on a list box item sends requests to refresh all the
data, and if the user were to use the keyboard to quickly scroll
through the listbox, many many calls would get queued up. 

I've tried setting the concurrency= last on the httpservices, but it
appears the only effect of that is to make the UI change only when the
last dataset is received, but still all the service calls continue to 
be queued and there is a long delay after making many calls.

I've also tried httpservice .disconnect( ) and .cancel() before making
any new backend call but it didn't appear to have any effect as far as 
preventing many calls from getting queued up.

Thanks in advance for any ideas. I know I could also look into
retrieving all the data only once and doing local Flex filtering on it
rather than getting the data fresh from the backend each time, but for 
now it's just easier to make the backend calls and use the DB to do
the proper filtering and querying.








[flexcoders] Sending multiple HTTPService requests - how to really cancel all but the last

2007-04-07 Thread coderdude2
I'm using several HTTPService calls to plain old REST API's on the
backend.

If the end user clicks some of the UI controls multiple times quickly,
many calls to these services get queued up, and it can take a long
time for all the data to be retrieved.

For ex. clicking on a list box item sends requests to refresh all the
data, and if the user were to use the keyboard to quickly scroll
through the listbox, many many calls would get queued up.

I've tried setting the concurrency=last on the httpservices, but it
appears the only effect of that is to make the UI change only when the
last dataset is received, but still all the service calls continue to
be queued and there is a long delay after making many calls.

I've also tried httpservice.disconnect() and .cancel() before making
any new backend call but it didn't appear to have any effect as far as
preventing many calls from getting queued up.

Thanks in advance for any ideas. I know I could also look into
retrieving all the data only once and doing local Flex filtering on it
rather than getting the data fresh from the backend each time, but for
now it's just easier to make the backend calls and use the DB to do
the proper filtering and querying.