Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use lhttpc instead of httpc #13

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Use lhttpc instead of httpc #13

wants to merge 6 commits into from

Conversation

zp-sd
Copy link

@zp-sd zp-sd commented Jan 15, 2019

09:55:22.062 [error] gen_server <0.1348.0> terminated with reason: no function clause matching http_transport:close(undefined, #Port<0.2267>) line 346
09:55:22.062 [error] CRASH REPORT Process <0.1348.0> with 0 neighbours crashed with reason: no function clause matching http_transport:close(undefined, #Port<0.2267>) line 346
09:55:22.062 [error] Supervisor httpc_handler_sup had child undefined started with {httpc_handler,start_link,undefined} at <0.1348.0> exit with reason no function clause matching http_transport:close(undefined, #Port<0.2267>) line 346 in context child_terminated
  • Avoid crash report when httpc_handler_sup is killing its children after unsuccessful httpc:request/1 function call.
    It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off.
    Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).
11:40:40.047 [error] gen_server <0.1176.0> terminated with reason: {tcp_error,#Port<0.246021>,etimedout}
11:40:40.069 [error] CRASH REPORT Process <0.1176.0> with 0 neighbours exited with reason: {tcp_error,#Port<0.246021>,etimedout} in gen_server:handle_common_reply/8 line 726
11:40:40.069 [error] Supervisor httpc_handler_sup had child undefined started with {httpc_handler,start_link,undefined} at <0.1176.0> exit with reason {tcp_error,#Port<0.246021>,etimedout} in context child_terminated

@benoitc
Copy link
Owner

benoitc commented Jan 15, 2019

@zp-sd as said on slack I would use hackney instead of lhttpc. I'm the maintainer of hackney so any updated needed would be easier. Can you make the change?

one question is if checking if setting the option to a profile using httpc:set_options/1 wouldn't do the trick so it wouldn't force the use to have a dependency to hackney and just rely on Erlang/OTP ?

@benoitc
Copy link
Owner

benoitc commented Jan 15, 2019

@zp-sd if you have a simple way to test we can eventually try the second method. Let me know :)


Req = {Url, Headers, "text/xml; charset=\"utf-8\"", Msg},

case httpc:request(post, Req, [], Options) of

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided that the caller passes a profile not used by concurrent requests, would avoiding to place the httpc process in the supervisor solve the issue? Requires somehow determining profile to use in httpc call.

Refs:

Snippet:

httpc_request(Method, Request, HTTPOptions, Options, Profile) ->
    {ok, Pid} = inets:start(httpc, [{profile, Profile}], stand_alone),
    Response = httpc:request(Method, Request, HTTPOptions, Options, Pid),
    ok = gen_server:stop(Pid, normal, infinity),
    Response.

Past usages that may be referred to:

benoitc and others added 5 commits January 18, 2019 11:30
test path on amplifi router
* Aviod a crash in http_transport:close/2, happening when setting socket_opts in httpc in OTP 20.1.
The fix for the bug is included in OTP 21 - https://bugs.erlang.org/browse/ERL-605.

* Avoid crash report when httpc_handler_sup is killing its children after unsuccessful httpc:request/1 function call.
It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off.
Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).
* Aviod a crash in http_transport:close/2, happening when setting socket_opts in httpc in OTP 20.1.
The fix for the bug is included in OTP 21 - https://bugs.erlang.org/browse/ERL-605.

* Avoid crash report when httpc_handler_sup is killing its children after unsuccessful httpc:request/1 function call.
It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off.
Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).
@jadeallenx
Copy link

Given that we're on OTP 22/23 these days, the PR seems moot?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants