flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Crews (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FLEX-34475) HTTPService requestTimeout permanently clamps to a default value
Date Wed, 20 Aug 2014 22:47:26 GMT
Jesse Crews created FLEX-34475:

             Summary: HTTPService requestTimeout permanently clamps to a default value
                 Key: FLEX-34475
                 URL: https://issues.apache.org/jira/browse/FLEX-34475
             Project: Apache Flex
          Issue Type: Bug
          Components: RPC: HTTPService
    Affects Versions: Apache Flex 4.12.1
         Environment: Microsoft Windows 7, AIR 13.0
            Reporter: Jesse Crews
            Priority: Minor

Problem Description:
HTTPService's requestTimeout property can set the requestTimeout and idleTimeout of the underlying
URLRequest. However, it is possible to permanently (until application termination) clamp the
idleTimeout to the first request's idleTimeout value (internally propagated from requestTimeout).

Steps to Reproduce:
Create at least two HTTPService objects. Set a short timeout (e.g., 10 seconds) and a long
timeout (e.g., 120 seconds) for each request, respectively via the requestTimeout property.
Call the short timeout service's send() first.

Actual Result:
Subsequent requests always throw a #2032 stream error fault before the specified requestTimeout,
exactly when the first request's requestTimeout expires. The first request need not complete
before the second is send()t; the result is the same. 

This condition is not recoverable without restarting the application. The first HTTPService
requestTimeout becomes the global maximum. 

Expected Result:
Each HTTPService faults only when its specified requestTimeout has expired. 

Any Workarounds:
Send an HTTPService request with a requestTimeout equal to or greater than the application's
maximum requestTimeout. It need not succeed in order to set the runtime state to a predictable
one. In fact it can be cancel()ed and still achieve the desired effect.

NetworkTester.mxml is a thrown-together (5 minute) example. If "ping" is sent first, then
subsequent "send" presses with result in a fault after 15 seconds if the delay is >= 15.
test.php just sleep()s for the delay period and echos a string back.

If "send" is pressed first, then any subsequent sequences of "ping" or "send," in any order,
will properly fault at their specified requestTimeout expiration time.

Additional note:
The observed platform default timeout is 30 seconds. If the workaround in lines 26-32 is enabled,
the effect will persist until the machine is rebooted (after recompiling with the comments
restored). If ping is pressed, the undesired effect outlined above occurs exactly as before.

Setting URLRequestDefaults.idleTimeout before each request does not have the desired effect
the workaround does.

This message was sent by Atlassian JIRA

View raw message