[erlang-questions] escript's beam in in distributed environment

[Angel J. Alvarez Miguel]

Sorry for so long delay,

 im reading older unread messages in my box...




You can try this to distribute code onto remotre nodes.(assume



distribute_app(Modules) ->
        %% extraer todos los nodos excepto el Master
        RemoteNodes = [X || X <- pool:get_nodes(), X =/= node()],
        %% Transferir el código
        lists:foreach(fun(Node) -> transfer_code(Node, Modules) end, RemoteNodes).

transfer_code(Node, Modules) ->
        [transfer_module(Node, Module) || Module <- Modules].

transfer_module(Node, Module) ->
        {_Module, Binary, FileName} = code:get_object_code(Module),
        rpc:call(Node, code, load_binary, [Module, FileName, Binary]).

Or you can user "--inet loader"

slave:start("192.168.X,Y","remote_node_test", ["-host 192.168.my.IP -loader inet "++"-setcookie "++erlang:get_cookie()] ).

and also youll need to pass same options when use pool:start(Name,Args) for getting a bunch of nodes.

Note that you need additional setup on your code server to aloow reuqest from those new remote nodes, just check erl -man erl_boot_server

Whenever some remote node need to load a new beam it asks your local boot_server server instead of going to the FS so avoids to distribute, 
or share your beams via NFS and also without the need to extract them form the script...


Ive tested this (no production yet) and seems to work... (well there are some trouble in "slave" when you spawn a lot of nodes but this is another story..)
regards, Angel


On Martes, 7 de Febrero de 2012 11:45:53 karol skocik escribió:
> Hi,
>   I want to have an escript, which starts some slave nodes making
> requests to some target host - basically a simple load generator.
> On a slave nodes, running functions from escript directly fails, since
> slaves can't find those escript functions, which is understandable.
> For that purpose, the escript contains this function:
> 
> make_beam() ->
>     Name = escript:script_name(),
>     AbsName = filename:absname(Name),
>     {ok, Sections} = escript:extract(AbsName, [compile_source]),
>     {source, BeamCode} = lists:keyfind(source, 1, Sections),
>     BeamFile = filename:join("/tmp", atom_to_list(?MODULE) ++ ".beam"),
>     file:write_file(BeamFile, BeamCode),
>     BeamFile.
> 
> The plan was:
> 1.) save the escript as a beam to the "/tmp" directory (with a funky
> name from ?MODULE - like 'gcf-tester__escript__1328__608633__210866')
> 2.) add "/tmp" to the code path on master, before starting slaves
> 3.) let the slaves load module (named ?MODULE in escript) using code
> load mechanism thru master
> 
> Now the problem:
> 
> When the saved escript's beam is loaded in the Erlang shell, it seems
> broken:
> 
> (gcfc@REDACTED)5> code:add_patha("/tmp").
> true
> (gcfc@REDACTED)6> l('gcf-tester__escript__1328__608402__188688').
> {error,badfile}
> (gcfc@REDACTED)7>
> =ERROR REPORT==== 7-Feb-2012::10:54:09 ===
> Loading of /tmp/gcf-tester__escript__1328__608402__188688.beam failed:
> badfile
> 
> =ERROR REPORT==== 7-Feb-2012::10:54:09 ===
> beam/beam_load.c(1084): Error loading module
> 'gcf-tester__escript__1328__608402__188688':
>   module name in object code is gcf-tester__escript__1328__608402__542812
> 
> I am using:
> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2]
> [async-threads:0] on:
> Gentoo Linux 2.6.38-tuxonice-r2-mars #9 SMP PREEMPT x86_64 Intel(R)
> Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
> 
> Is this a bug? (Maybe fixed in R15?).
> If this is an expected behavior, how do I know the final module name
> at the time of creating the escript's beam?
> And finally, what's the easiest way to "patch" the beam's binary to
> supply the correct module name?
> 
> Thank you for your advice,
>   Karol Skocik
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions