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] [Issue Comment Deleted] (FLEX-34475) HTTPService requestTimeout permanently clamps to a default value
Date Wed, 20 Aug 2014 22:51:29 GMT

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

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

    Comment: was deleted

(was: 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)

Mime
View raw message