[appserver-io/appserver] Refactoring bootstrap process

[wagnert]

Actually the bootstrapping process is not well defined. A result of that is, if concurrency problems occur, they are hard to locate.

The bootstrap process has to be refactored:

• Bootstrap should be invoked by one method in Server class, e. g. Server::bootstrap()
• Bootstrap process MUST be configurable by a XML file (Workflow-Engine)
• Bootstrap process MUST be aware of directories that has to be created/cleared
• Bootstrap process MUST be extensible by hooks
• Installation functionality from server.php MUST be realised as hook

After a review of the actual bootstrap process, we created a section that describes the basic architecture and the necessary bootstrap steps, as they are actually implemented.

Additionally to the refactorings defined above, the following optimisations MUST be implemented.

Asynchronous Deployment of Applications

• See issue [appserver-io/appserver] Asynchronous Deployment of Applications #760 for more details.

In version 1.0.x the deployment of applications must be finished, before the servers can start, because modules like the Message Queue needs the application data to be fully initialised. Asynchronous Application Deployment results in three major advantages

• Application Deployment can be invoked with the permissions of the configured user and not with root permissions
• Application Deployment can't block application server start-up
• Restarting the server will be faster in some cases, because servers don't need to wait for all applications to be deployed

Bootstrap Segementation

In version 1.x, the root class Server is used to start two processes. Process 1 provides the main application server functionality and starts the configured containers, servers and applications. Whereas process 2 only starts the scanner, the PHAR deployment, the log rotation as well as the directory watcher (which is deactivated by default) functionality.

Runlevels

• See Issue [appserver-io/appserver] Runlevels #761 for more details

To optimise resource usage, the bootstrap process MUST be segmented into 7 steps. The bootstrap process reminds a bit to the Linux bootstrapping process.

ID	Name	Description
0	Shutdown	Stop the Application Server
1	Administration	Start the Base System
2	Daemon	Start the Core Daemons
3	Networking	Start the Containers
4	Secure	Secure the Application Server
5	Full	Initialise and Start the Applications
6	Restart	Restart the Application Server

The following table maps each of the service of version 1.x to one of the new runlevels.

ID	Name	Description
0	Shutdown	Stop the Application Server
1	Administration	Start the Base System
1.1	Administration	Set the Umask
1.2	Administration	Initialize + Start the InitialContext
1.3	Administration	Initialize + Start the Filesystem
1.4	Administration	Initialize + Start the Loggers
1.4	Administration	Initialize + Start the Console
2	Daemon	Start the Core Daemons
2.1	Daemon	Initialize + Start the Scanners
3	Networking	Start the Containers
3.1	Networking	Initialize + Start the Containers
3.2	Networking	Initialize + Start the Modules
3.3	Networking	Initialize + Start the Servers
3.4	Networking	Initialize + Start the Containers
4	Secure	Secure the Application Server
4.1	Secure	Switch to the configured User
5	Full	Initialise and Start the Applications
5.1	Full	Initializes + Start the Extractors
5.2	Full	Initializes + Start the Applications
5.3	Full	Initializes and Start the Provisioners
6	Restart	Restart the Application Server

The runlevels are processed in a procedural way. This means, when the requested runlevel is reached (default runlevel is 1), the server waits for a user requesting a new runlevel, which may also has a lower ID. For example it MUST be possible, that the server can switch from runlevel Full to Administration for maintenance purposes. Therefore Services and Daemons that have been started in a higher runlevel has to be shut down when switching to a lower one.

Events

• See Issue [appserver-io/appserver] Events #762 for more details

Processing a runlevel results in firing an event. Therfore, all services described above has to be started when the event for the runlevel is fired. Services still have to be registered in the application server's configuration file etc/appserver/appserver.xml.

Management Console

• See Issue [appserver-io/appserver] Management Console #763 for more details

The Management Console provides a commandline for executing administrative tasks. When a user tries to connect to the Management Console, he has to authenticate first. Therefore, login credentials has to be available in the servers naming directory.

exit

The exit command closes the shell for the actual user. If the su command has been used, it'll switch back to the previous user.

init

The init command allows Administrators, Developers or Deployers to switch between the different runlevels.

administrator $ init 5
administrator $ Switching from runlevel 1 to 5
administrator $ Runlevel 2 - Successfully started Core Daemons
administrator $ Runlevel 3 - Successfully started Containers
administrator $ Runlevel 4 - Successfully switch to configured User
administrator $ Runlevel 5 - Successfully started Applications
administrator $

su

The su command switches the user. If necessary, the password of the user to be switched, has to be entered.

administrator $ su other-user
administrator $ Please Enter Password: *****
other-user $ 

top

The top command gives a dyamic overview of all threads as well as the amount of memory and CPU time the require.

status

The status command gives a textual overview about the servers status

administrator $ status
administrator $ - Processes Started: 246
administrator $ - Memory Used: 259.6 MB
administrator $ + Run following Daemons
administrator $  | - Deployment Scanner (deployment-scanner)
administrator $  | - Log Rotate Scanner (log-rotate-scanner)
administrator $  | - Recursive Directory Scanner (directory-scanner)
administrator $ + Run following Containers
administrator $   + - Combined Container (combined-container)
administrator $    | - Message Queue Server (message-queue) : Port 8587
administrator $    | - HTTP Server (http): Port 80
administrator $    | - HTTPS Server (https): Port 443

service

The service command allows to start or stop services

administrator $ service combined-container start
administrator $ Successfully started service combined-container