[Erlang 0025] understanding Erlang/OTP-Application

1> application: Start (log4erl ).

Let's start with this command line. After you press enter, you can start the log4erl application. the component that can complete a specific set of functions in Erlang/OTP is called application ., application is one of the forms of Erlang code and function Organization ([Erlang 0015] Erlang OTP design principles ). application is designed to run one or more processes to complete certain functions. to be able to manage the lifecycle of these processes, you need to manage them through the supervisor.

Application: Start (log4erl ). actually, the application: Start (log4erl, temporary) is executed ). the second parameter indicates the Startup Type of the application (start_type ). the Startup type can also be permanent transient. The difference between the three startup types is: If start_type = permanent, after the application is terminated, all other applications and runtime systems will die; if the start_type = transient application is terminated due to normal, the message is reported, but other applications are not restarted. If the application is not terminated due to normal, other applications and runtime will also die. If start_type = temporary application dies, an error will be reported, but other applications will not be affected. note that the transient parameter is rarely used in practice. When the process tree crashes, the cause of normal process exit is that shutdown is not normal. As mentioned in my previous article: [Erlang 0017] No matter which type of start is used, directly calling the stop method to close the application will not affect other applications.

I have encountered a serious problem that caused the application to collapse. At that time, some colleagues asked why the Erlang process is still running or still alive? In fact, it is because temporary is used by default when we start the application;

Application configuration file
The application configuration file basically determines the application pattern. if the startup fails, check the configuration file. The name of the configuration file must be the same as that of the application, that is, there must be a log4erl. app file:

 

{Application, log4erl,
[{Description, "logger for Erlang in the spirit of log4j "},
{Vsn, "0.9.0 "},
{Modules, [lele_appender, % This configuration section can be left blank []
Dummy_appender,
Email_msg,
Error_logger_log4erl_h,
% ...... Omitted some modules
Xml_appender]},
{Registered, [log4erl]}, % The registration name that the application will use
{Applications, [kernel, stdlib]}, % note that this configuration section specifies which applications the current application depends on, similar to the Windows Service dependency.
{Mod, {log4erl, []},
% {ENV, [{key, value}, {K2, V2}]}, % env configuration section, which organizes configuration data in the form of key-value. you can use application: get_env/2 to read data.
{Start_phases, []}
]}.

Application Startup Process

 

When Erlang is started, the application controller process starts with the kernel application. In Erlang shell, you can find it through whereis (application_controller. the operations related to the application are coordinated by it. It loads, uninstalls, starts, stops, and so on through the interfaces exposed by the application module.

Load is first loaded before the application starts. If application controller is not loaded, load/1 is first executed. after the application controller is loaded, the system checks that all applications listed in the application configuration section in the application configuration file are running. if a dependency item has not been started, the {error, {not_started, app} error is thrown.

After the dependency check is completed, application controller creates an application master for the application. the application master will become the group leader of all processes in the application. (the group leader determines the position of the output redirection. For details, refer to the question: how to call a function of Node B from node A and output the result to Node B ?) . In the MOD configuration section of the configuration file, the application master knows to call 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 and how to stop. call the start method when starting the application to create a process tree by starting the top-level supervisor. log4erl implements the behavior of the application, and its start method is also equivalent to starting the top-level superior:

Start (_ type, [])-> log4erl_sup: start_link (? Default_logger). % here? The ult_logger macro value is default_logger.

 

Start has specifications for the returned value: Start (starttype, startargs)-> {OK, PID} | {OK, PID, State}

When the returned results are inconsistent, the application naturally fails to start. The most common error during beginners is to add an output to check whether the application is started. The result is tragic. for example, in the following code, the return value of the Start function is the value of the last expression IO: format, and the result is OK, which does not meet the requirements of the application 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 the application, the application master first calls module: prep_stop/1 (if any), and then notifies the top-level supervisor to close (shutdown). The shutdown process is as follows: all processes and applications of the entire monitoring tree are terminated in the reverse order of startup. after shutdown is completed, the application master calls module: Stop/1. the application master is terminated. the application is stopped, but it is still in the loaded state (loaded ).

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

 

Start appmon: Start () to get a more intuitive impression. the following describes how log4erl application processes are organized. log4erl_sup is the top-level supervisor of log4erl application. The preceding <0.42.0> and <0.43.0> are described as application master processes, we verify by taking 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 },
{Functions, 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 },
{Functions, 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> come here today, good night! Log4erl Project address http://code.google.com/p/log4erl/