[jira] [Updated] (FLEX-34475) HTTPService requestTimeout permanently clamps to a default value

["Jesse Crews (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLEX-34475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse Crews updated FLEX-34475:
-------------------------------

    Attachment: NetworkTester.mxml

Example code

> 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
>         Attachments: NetworkTester.mxml
>
>
> https://bugbase.adobe.com/index.cfm?event=bug&id=3691973
> 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
(v6.2#6252)