Dead lock after requests timed out ?

128 views
Skip to first unread message

Ralph

unread,
Sep 1, 2011, 12:27:44 AM9/1/11
to ASIHTTPRequest
Hi,

I'm trying to solve an issue where after a time out of 4 requests
(maxConcurrentOperationCount=4), the remaining requests in the queue
are not being processed anymore even though
shouldCancelAllRequestsOnFailure is set to NO.

I'm not really sure what's happening and I hope someone can help.

ASIHTTPRequest is in v1.8.1-33 as of 2011-08-23.


Here's how to replicate it using ASIWebPageRequest in the sample
application.

Modifications:
1)
WebPageViewController.m: set the download page (urlField) to:
[urlField setText:@"http://www.latimes.com/?mview=desktop"];

2)
ASIWebPageRequest.m: in both methods "parseAsCSS" and "parseAsHTML"
add the following line:
[[self externalResourceQueue] setShouldCancelAllRequestsOnFailure:NO];

Also, in "externalResourceFetchFailed:(ASIHTTPRequest
*)externalResourceRequest" comment out the line:
// [self failWithError:[externalResourceRequest error]];
We want the webpage request to continue despite few failures.
To see the time outs in the Console, add this line to the external
resource failed method:
NSLog(@"log: %@", [externalResourceRequest error]);


That's it. If you run the Simulator, go to "Web page", set "Replace
URLs with ..." to True and run the request you will see 4 time outs in
the Console and the web page fetch never completes.

(make sure to clear the cache in between tests if you repeat them !)


To continue, let's clear out the Simulator and delete the sample App
from it.


In a next step, increase the maxConcurrentOperationCount and the web
page fetch will complete.

In both "ASIHTTPRequest.m" and "ASINetworkQueue.m" increase the
counter from "4" to "8" by updating the following line of code:
[sharedQueue setMaxConcurrentOperationCount:8];

In a clean Simulator, run the same test as described above and the web
page request will complete successfully.


As a first try, I also set the should use persistent connection to No,
but this did not help.


Why does the web page fetch complete if maxConcurrentOperationCount =
8 but not if maxConcurrentOperationCount = 4 ?

Could it be that the 4 operations that time out, never get "re-used"
or removed and consequently a new operation cannot start?


Thanks for reading, hope anyone can shine some light on this.

Best Regards,
Ralph

Ben Copsey

unread,
Sep 1, 2011, 2:59:18 AM9/1/11
to asihttp...@googlegroups.com
Hi Ralph

> I'm trying to solve an issue where after a time out of 4 requests
> (maxConcurrentOperationCount=4), the remaining requests in the queue
> are not being processed anymore even though
> shouldCancelAllRequestsOnFailure is set to NO.

I'm aware of the issues with ASIWebPageRequest and maxConcurrentOperationCount. I'll try to get a fix out this weekend. I also have a few other fixes and improvements for ASIWebPageRequest waiting to go, and an alternative class in the works (see https://groups.google.com/d/msg/asihttprequest/kX3oZUc_3DM/r9GBx_-EJqkJ).

Best,

Ben

Radhika

unread,
Sep 14, 2011, 8:00:06 AM9/14/11
to asihttp...@googlegroups.com

There is a temporary fix for the problem that works for me. The problem is,upon request timeout ASIWebpageRequest never calls super class(ASIHttpRequest) method markAsFinished which makes the timed out request to remain in the queue.

I made the changes to ASIWebPageRequest.m

1.In markAsFinished method

  • (void)markAsFinished { if (error) { [super markAsFinished]; }

}

Added the [super markAsFinished] call in case of an error.

  1. In externalResourceFetchFailed method

  2. (void)externalResourceFetchFailed:(ASIHTTPRequest *)externalResourceRequest
    {
    if([[self externalResourceQueue] shouldCancelAllRequestsOnFailure]){
    [self failWithError:[externalResourceRequest error]];
    }
    }

After making these changes i was able to download the webpage eventhough there are few timeouts and failures.
Note: Need to add the line [[self externalResourceQueue] setShouldCancelAllRequestsOnFailure:NO]; to the methods parseAsHTML and parseAsCSS as mentioned in the bug.

RALPH KESSLER

unread,
Sep 15, 2011, 7:35:47 PM9/15/11
to asihttp...@googlegroups.com, Radhika
Hi Radhika,

fantastic.
Thanks a lot for the explanation.

I did a first trial run with your proposed changes and I can confirm that this has solved the issue.

Best,
Ralph




--
You received this message because you are subscribed to the Google Groups "ASIHTTPRequest" group.
To view this discussion on the web visit https://groups.google.com/d/msg/asihttprequest/-/RitNdbIA8L4J.
To post to this group, send email to asihttp...@googlegroups.com.
To unsubscribe from this group, send email to asihttpreques...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/asihttprequest?hl=en.

Reply all
Reply to author
Forward
0 new messages