> Hi there,
>
> I wonder if someone can help me on this...I have tried for a couple
> days now and am about to pull out my hair ;-)
>
Save your hair, this one's fairly easy to fix :)
>
> erl -pa ./ -boot start_sasl -sasl errlog_type error -run karoona_http
> start 8001
The -run and -s arguments take a module and a function and collect the
following arguments into a single list, so "-run karoona_http start
8001" is not karoona_http:start(8001) but actually
karoona_http:start([8001]).
The fix is pretty simple, modify
start(Port) ->
...
to
start([Port]) -> start(Port);
start(Port) when is_integer(Port) ->
> application:start(log4erl),
> log4erl:add_file_appender(file, {"./", "log", {size, 100000}, 4,
> "txt", debug}),
> log4erl:debug("Karoona starting...ready to Rock n Roll!!"),
>
> case mochiweb_http:start([{loop, fun handle_requests/1}, {port,
> 8001}]) of
> {ok, MochiPid} ->
> log4erl:debug("Mochiweb started...");
> {error, Reason} ->
> log4erl:debug("Mochiweb died, reason:~s...", [Reason])
> end.
OTP has printed the error message for you here - you can see the nested
argument list:
> {"init terminating in do_boot",{undef,[{karoona_http,start,[['8001']]},
Cheers,
--
Geoff Cant
> Hi Geoff,
>
> I see the Port was actually seen as an ATOM.....so I changed the code
> to the following:
That's really quite odd - I don't know why that's happening, but you are
correct from the error I saw.
> NOTE: the added "Port2 = erlang:list_to_integer(erlang:atom_to_list
> (Port)),"
The error leading to {error, closed} is a bit subtle.
> -export([start/1, stop/0, ping/1]).
To process -run or -s arguments, erlang spawns a process to evaluate the
M:F(A) you pass on the command line.
> start([Port]) ->
> application:start(log4erl),
> log4erl:add_file_appender(file, {"./", "log", {size, 100000}, 4,
> "txt", debug}),
> Port2 = erlang:list_to_integer(erlang:atom_to_list(Port)),
> start(Port2);
>
> start(Port) when is_integer(Port) ->
> log4erl:debug("Karoona starting...ready to Rock n Roll!!"),
>
> case mochiweb_http:start([{loop, fun handle_requests/1}, {port,
> Port}]) of
> {ok, MochiPid} ->
> log4erl:debug("Mochiweb started...");
> {error, Reason} ->
> log4erl:debug("Mochiweb died, reason:~s...", [Reason])
> end.
> =CRASH REPORT==== 22-Aug-2009::16:40:57 ===
> crasher:
> initial call: mochiweb_socket_server:acceptor_loop/1
> pid: <0.52.0>
> registered_name: []
> exception exit: {error,closed}
> in function mochiweb_socket_server:acceptor_loop/1
> ancestors: [mochiweb_http,<0.1.0>]
The error {error, closed} must come from a mochiweb socket acceptor
process calling gen_tcp:accept on the listen socket opened by the
mochiweb_socket_server process. The socket being closed when accept is
called would produce this error.
Maybe the process evalutating -run/-s (i.e. executing
karoona_http:start) exits which causes the socket_server and the listen
socket to exit, the acceptor processes survive, but the socket dies with
the socket_server and so you get {error, closed}
I'm not sure about this theory as the code for the
mochiweb_socket_server process traps exits, which should isolate the
listen socket from the socket server's parent exiting.
Does your code behave differently if you spawn a supervisor with one
child - use mochiweb_http:start(YourOptions) as the start function? In
this case the parent of the mochiweb_socket_server will be the
supervisor, which will survive past the -run/-s option processing phase
of startup.
If the above does work, then there's a bug somewhere or an API
assumption we're missing.
Cheers,
--
Geoff Cant
ps: resent due to mx weirdness.