By waking I meant switching them from CONNECT_PEND to the CONNECT state. The handle which I marked as X completes as expected however all the other handles remain forever in the CONNECT_PEND state.

---
** [bugs:#1465] Easy handle might hang in CURLM_STATE_CONNECT_PEND state after error reply**
**Status:** open
**Created:** Mon Dec 29, 2014 01:34 AM UTC by Jiri Dvorak
**Last Updated:** Fri Mar 20, 2015 10:35 AM UTC
**Owner:** Daniel Stenberg
Easy handle might hang in CURLM_STATE_CONNECT_PEND state after error reply.
Version: libcurl 7.39.0 however the problem did appear with 7.37.0 as well.
It seems that there is problem when using CURLMOPT_MAX_HOST_CONNECTIONS or CURLMOPT_MAX_TOTAL_CONNECTIONS options which can cause the handles which did transition to CURLM_STATE_CONNECT_PEND because of the limit to fail to be waken if the active requests fails with error. The appearance of the problem is fairly random.
As part of test of my program I have CURLMOPT_MAX_HOST_CONNECTIONS set to 1, CURLMOPT_MAX_TOTAL_CONNECTIONS to 4 and pipelining left on the default disabled state. I create 5 simultaneous easy-handles to do HTTP get of a non-existent URL (HTTP 404) using single multi-handle from Nginx running on localhost. Most of the time the operations complete without problem however sometimes, depending on timing and system load, some from them complete and remaining ones end stuck in CURLM_STATE_CONNECT_PEND state.
It looks like the following is happening when the hang happens:
1. Handle X starts download.
2. Remaining handles detect that connection is not available and enter CONNECT_PEND state
3. Sometimes latter the handle X transitions DO => DO_DONE and and switches all waiting handles to CONNECT.
4. Handle X switches to WAITPERFORM and then to PERFORM.
5. Remaining handles try to obtain the connection and see that it is still not available so switch back to CONNECT_PEND.
6. Handle X enters to the _"The transfer phase returned error, we mark the connection to get...."_ (multi.c:1552) path and closes the connection.
7. Handle X enters the error handling path within _"if(data->mstate < CURLM_STATE_COMPLETED) {"_  (multi.c:1699), data->result is CURLE_HTTP_RETURNED_ERROR and as the data->easy_conn is already a NULL, it simply enters CURLM_STATE_COMPLETED without waking anyone.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.