Understanding Erlang/otp-application

Http://www.cnblogs.com/me-sa/archive/2011/12/27/erlang0025.html

1>application:start (Log4erl).

Let's start with this line of command, you can start the Log4erl application after the carriage return. The components in ERLANG/OTP that can complete a particular feature set are called Application. , application is one of the forms of Erlang Code and functional Organization ([Erlang 0015]erlang OTP design principles). Application is designed to perform certain functions by running one or more processes. To be able to manage the lifecycle of these processes, it needs to be managed through supervisor.

Application:start (Log4erl). The Application:start (log4erl,temporary) is actually executed. The second parameter represents the startup type of the application (start_type). The startup type can also be permanent transient, and the difference between the three startup types is that all other applications and runtime systems will die if the start_type==permanent application terminates, if start_type== Transient application termination is due to normal, this message will be reported but other applications will not be restarted, if the application terminates because the cause is not normal, other applications and runtime will also be followed by death; if Start_type==temporary Applications that die will report errors but other applications are not affected. Note that the transient parameter is seldom used in practice, because the process tree collapses, the process normally exits because shutdown is not normal, as I mentioned earlier in this article: [Erlang 0017] ERLANG/OTP Base Module Proc_lib no matter which type of boot is used, calling the Stop method directly to close application will not affect other applications.

I've had a serious problem that caused the application to collapse, and then a colleague asked why Erlang's process is still alive, or is it running? In fact, we use temporary when we launch the application.

application configuration file
The application configuration file (application Resource file) basically determines the pattern of the application. If the boot fails, you should check the configuration file, and the configuration file naming requirements must be the same as the application name. That is, you must have a Log4erl.app file:

{Application, Log4erl,
[{description, "Logger for Erlang in the spirit of Log4j"},
{VSN, "0.9.0"},
{modules, [Console_appender, percent of  the configuration section can be left blank []
     Dummy_appender,
     Email_msg,
     Error_logger_log4erl_h,
     % ................ Omit some modules
     Xml_appender]},
{Registered,[log4erl]}, percent of the registration name that this application will use
{applications, [Kernel,stdlib]}, percent percent note this configuration section is a dependency that specifies which applications the current application depends on, like Windows services
{mod, {log4erl,[]}},
%{ENV,[{KEY,VALUE},{K2,V2}]},%env configuration section, which organizes configuration data in key-value form. Can be read with APPLICATION:GET_ENV/2.
{start_phases, []}
]}.

Application startup Process

When the Erlang runtime is started, the application controller process starts with the kernel application and can be Whereis (Application_controller) in the Erlang shell. Find it. Application-related operations are coordinated by the application module, which implements the application loading, unloading, starting, stopping, and so on, through interfaces exposed by the modules.

The load is loaded first before the application starts, and if no application controller is not loaded, the LOAD/1 is executed first. Load Complete Monkey puppet application The controller checks that the applications listed in the Applications configuration section in the application configuration file are already running. Throws {Error,{not_started,app}} error if there are dependencies that have not started.

After the dependency check is complete, the application controller creates a application for application Master.application master becomes the group for all processes in the application Leader. (group leader determines the location of the output redirect, see this question: How to invoke a function of the B-node from a node, and output the result to the B-node?) . With the MoD configuration section of the configuration file, application master knows to invoke the callback function LOG4ERL:START/2.

Application behavior has two callback functions that need to implement START/2 STOP/1 to specify how the application starts, How to stop. Call the Start method when you start application to create a process tree by starting supervisor on the top level. Log4erl realizes the application behavior, Its Start method is also well-behaved to start the top-level superior:

start(_Type, []) ->    log4erl_sup:start_link(?DEFAULT_LOGGER). %%这里?DEFAULT_LOGGER宏的值为default_logger

Start has a specification for return values: Start (StartType, Startargs), {OK, Pid} | {OK, Pid, State}

When the return result is inconsistent, the application naturally fails to start, the most common mistake is to add the output to see if it is started, the result is tragic. For example, the following code, the return value of the start function is the value of the last expression Io:format, and the result is OK, does not conform to application's requirements for the result of the start callback function.

start(Startype,Arg) ->    demo_sup:start_link(),    io:format("demo app start").

Application Stop Process

To stop Application,application Master first calls MODULE:PREP_STOP/1 (if present) and then informs the top-level supervisor off (shutdown), the process of shutdown: All processes and applications contained in the entire monitoring tree are terminated in reverse order of startup. After shutdown is complete, application master calls MODULE:STOP/1. Last application Master himself terminates. The application is stopped, but is still in the loaded state (loaded).

%log4erl stopstop(_State) ->    log_filter_codegen:reset(),    ok.

Start Appmon:start () to get a more intuitive impression. Here's how the Log4erl application process is organized, LOG4ERL_SUP is Log4erl application's top supervisor, above <0.42.0> and <0.43.0> as described above should be the application master process, which we verify by fetching process information:

 4> erlang:process_info (PID (0,42,0)).
[{current_function,{application_master,main_loop,2}},
{initial_call,{proc_lib,init_p,5}},
{status,waiting},
{message_queue_len,0},
{messages,[]},
{links,[<0.6.0>,<0.43.0>]},
{dictionary,[{' $ancestors ', [<0.41.0>]},
{' $initial _call ', {application_master,init,4}}]},
{Trap_exit,true},
{Error_handler,error_handler},
{Priority,normal},
{Group_leader,<0.42.0>},
{total_heap_size,233},
{heap_size,233},
{stack_size,6},
{reductions,23},
{garbage_collection,[{min_bin_vheap_size,46368},
{min_heap_size,233},
{fullsweep_after,65535},
{minor_gcs,0}]},
{suspending,[]}] 5> erlang:process_info (PID (0,43,0)).
[{current_function,{application_master,loop_it,4}},
{initial_call,{application_master,start_it,4}},
{status,waiting},
{message_queue_len,0},
{messages,[]},
{links,[<0.42.0>,<0.44.0>]},
{dictionary,[]},
{Trap_exit,true},
{Error_handler,error_handler},
{Priority,normal},
{Group_leader,<0.42.0>},
{total_heap_size,233},
{heap_size,233},
{stack_size,5},
{reductions,65},
{garbage_collection,[{min_bin_vheap_size,46368},
{min_heap_size,233},
{fullsweep_after,65535},
{minor_gcs,0}]},
{suspending,[]}] 6> application:stop (log4erl). Ok

=info report==== 27-dec-2011::20:29:47 = = =
Application:log4erl
exited:stopped
Type:temporary
7> erlang:process_info (PID (0,43,0)).
Undefined
8> erlang:process_info (PID (0,42,0)).
Undefined
9> first here today, good night! Log4erl Project Address http://code.google.com/p/log4erl/

Understanding Erlang/otp-application