1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<tt>
<br>
<div><br>
<span style="font-size: 12px;">That would be perfect! Do you want me to make the change and issue a pull request?</span><br>
</div><br>
<div><div><br></div><div>-- </div><div>Dr Adrian Roe</div><div>Director<br></div><div><br></div></div><br>
<br>
<p style="color: #A0A0A8;">On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:</p><br>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><br>
<span><div><div><div>I don't think the problem is that the handler is reused, we don't reuse </div><div>them if there's an error. However we do catch errors to print them in </div><div>the logs, and then the process stops normally. If you link without </div><div>trap_exit you receive a normal exit signal which is ignored and doesn't </div><div>kill your process. I suppose we should throw an exit signal when we got </div><div>an error, after logging everything, instead of stopping normally.</div><div><br></div><div>On 07/18/2013 12:31 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>My issue is the other way round. My handler crashes - and terminate</div><div>gets called, but the linked process is NOT stopped (unless I stop it in</div><div>terminate having stashed any processes I need to stop in the process</div><div>dictionary - this is what I'm currently doing, but yuck!)</div><div><br></div><div>. My question is whether it wouldn't be better to no re-use the handler</div><div>process that has crashed and replace it so that handler's can use the</div><div>canonical erlang way of stopping related processes rather than having to</div><div>do it by hand.</div><div><br></div><div>Obviously if the handler does not crash there's no need to kill the</div><div>process, so the current efficiency saving works in the "normal" case/</div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div>On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:</div><div><br></div><blockquote type="cite"><div><div>I don't know what happens but there's two things I know:</div><div><br></div><div>* Handlers don't trap_exit, so if the linked process crashes, they</div><div>crash too</div><div>* If the handler crashes, we close the connection and stop the</div><div>handler; if not this is a bug</div><div><br></div><div>After your log message the handler should stop unless there's a bug</div><div>somewhere.</div><div><br></div><div>On 07/18/2013 12:15 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>We have been using spawn_linked workers to handle tasks that live for</div><div>the lifetime of a single HTTP request</div><div><br></div><div>Although in the cowboy guide it is clear that Cowboy can use "One</div><div>Process of Many Requests" I am surprised that this is the case even if</div><div>the handler crashes. For example, our use case is to copy a large file</div><div>to the server over HTTP where a worker process relays the file contents</div><div>to long term storage. The worker process is spawn_linked from the HTTP</div><div>handler and (for our use case) should die if the handler stops.</div><div><br></div><div>If the client stops the upload (for example by browsing away, or losing</div><div>connectivity) we correctly receive an error (see sample Lager trace</div><div>below), but what we are seeing is that spawn_linked processes are NOT</div><div>being killed.</div><div><br></div><div>Is this intended behaviour - I accept it makes sense to reuse the</div><div>processes but should this continue to be the case even if the previous</div><div>use of the process crashed? If it is intended behaviour I think the</div><div>docs should highlight this as we've been leaking processes for some time</div><div>now, but I've always seen it as erlang's job to look after related</div><div>process trees in the event of error. Our current workaround is to hold</div><div>a list of linked processes in process storage and then kill them in the</div><div>terminate handler which is ugly in the extreme!! We don't know the PIDS</div><div>of the linked processes until it is too late to return State to Cowboy</div><div>(i.e. we are already in our handle code)...</div><div><br></div><div>Kind regards</div><div><br></div><div>Adrian</div><div><br></div><div>16:09:32.347 [info] Trailer upload failed with reason</div><div>{case_clause,{error,closed}}</div><div>16:09:32.348 [error] ** Cowboy handler upload_trailer_resource</div><div>terminating in handle/2</div><div>for the reason error:{case_clause,{error,closed}}</div><div>** Handler state was {state,undefined,0,undefined,undefined,undefined}</div><div>** Request was</div><div>[{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef</div><div>ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>">>},{<<"user-agent">>,<<"M</div><div>ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,</div><div>like Gecko) Chrome/28.0.1500.71</div><div>Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce</div><div>pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;</div><div>id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde</div><div>fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]</div><div>** Stacktrace:</div><div>[{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}</div><div>,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo</div><div>ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]</div><div><br></div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>Extend mailing list</div><div>[email protected] <<a href="mailto:[email protected]">mailto:[email protected]</a>></div><div><a href="http://lists.ninenines.eu:81/listinfo/extend">http://lists.ninenines.eu:81/listinfo/extend</a></div></div></blockquote><div><br></div><div><br></div><div>--</div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></div></span><br>
<br>
<br>
<br>
<br>
</blockquote><br>
<br>
<div><br>
<br><br>
</div><br>
</tt>
|