workerman-php / workerman-php/http-client

Connection closed

Open
#16 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
55
Forks
19
PR merge metrics
No merged PRs in 30d

Description

I decided use http client in my worker.
Server part works on workerman Worker with one thread ( $worker->count = 1; ) Business logic requires it.

Part of http client here :

$http = new Workerman\Http\Client(
['max_conn_per_addr' => 128,
  'keepalive_timeout' => 15,
   'connect_timeout'   => 30,
   'timeout'           => 30,
]);
$t=microtime(1);
$http->post('http://127.0.0.1:8080', ['command'=>'ping'], 
function ($response) { echo "ok\n"; }, 
function ($exception) use($t){ echo ' exception ['.substr($exception,0,57).']</b> diff:'.(microtime(1)-$t).s"\n"; }
);

So, when i post queries sequentially all work fine and quick. But if i send multiple quries - http client very quickly (0.1sec) recieve exception "Connection closed". I was expect that it will wait answer from server up to 30 seconds, but not.
If I use another asynchronous method of client operation via curl_multi I don’t observe such server behavior.
May be i need some tune of psr7 ? Or do you have any smart thoughts on this topic?

Thank you for your product and attention to it.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the concurrent requests through Workerman\Http\Client::post with the shown timeout and max_conn_per_addr settings, comparing sequential and rapid submissions. Check the single-worker setup and the curl_multi comparison described in the issue. Done means identifying the cause of the "Connection closed" result and confirming the expected behavior for concurrent requests.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.