Make WordPress Core

Opened 9 years ago

Last modified 5 years ago

#34796 accepted defect (bug)

Facing an issue when using wp_remote_get with streams (non-blocking mode)

Reported by: bangelov's profile bangelov Owned by: rmccue's profile rmccue
Milestone: Priority: normal
Severity: normal Version: 4.3.1
Component: HTTP API Keywords: has-patch reporter-feedback
Focuses: Cc:


On some hosting providers (like I've encountered an issue when using wp_remote_get with streams (non-blocking mode) which on the other hand uses PHP native functions stream_socket_client, stream_context_create and stream_set_blocking. The issue is that HTTP request (non-blocking) never succeed, it just hangs/stuck on the initial call of stream_socket_client and neither errors or exception are generated. I've investigated the issue deeper and it seems that many people over the Internet have it. The issue can be resolved after invoking stream_socket_client we put usleep(5000) and then stream_set_blocking($handler, 0). It seems that the initial time for stream_socket_client is not enough and that's why it needs more time in order to process the HTTP request.

PHP Bugtracker

WordPress 4.3.1
PHP 5.5

Is it possible to add additinal parameter on wp_remote_get or if there is any other way to achieve setting usleep parameter will help us to precisely configure HTTP requests.

I am adding patch file

Attachments (2)

class-http.diff (799 bytes) - added by bangelov 9 years ago.
34796.diff (676 bytes) - added by rmccue 9 years ago.
Wait for socket to be ready before writing to it

Download all attachments as: .zip

Change History (6)

9 years ago

9 years ago

Wait for socket to be ready before writing to it

#1 @rmccue
9 years ago

A timeout is a bit of a hack; attached a patch that uses select to wait for the socket to be ready for writing to. Right now, this is hardcoded to wait 50µs, but might need to be bumped higher; I can't reproduce this locally to determine a reasonable amount.

On my box that can't reproduce it, this adds 30µs of overhead, which is negligible.

@bangelov Can you try this out, and try bumping the 50 up to see if this fixes your issue? I'd try up to 100000 (0.1s). We want to keep this as low as possible (since it's a timeout), but high enough to allow a bit of waiting.

#2 @rmccue
9 years ago

  • Keywords has-patch reporter-feedback added
  • Milestone changed from Awaiting Review to Future Release
  • Owner set to rmccue
  • Status changed from new to accepted

#3 @bangelov
9 years ago

Hi @rmccue Thanks for your attention! I've tried the above code using stream_select but unfortunately it doesn't work on That is the main environment that I am using for the test, because I can reproduce the problem there. I've tested it with timeout 50, 500, 5000, 500000 and it stuck the same way as it was without stream_select. The only way I was able to made successful request was with usleep. Yes it's a bit of a hack but I am out of ideas what could be the problem. Btw I've dumped the response from stream_select and it's true so that function runs properly, but it doesn't prevent stuck problem. Do you have any other idea what we could try? Thanks!

Last edited 9 years ago by bangelov (previous) (diff)

#4 @dd32
8 years ago

@rmccue This seems like it'll be a problem in Requests too right?

Note: See TracTickets for help on using tickets.