Mindmajix

Managing the Application Server

we will describe the management tools that can be used to control your application server instances. Obviously, being a complete application server means that JBoss AS implements 100 percent of the Java EE 6 specifications, but it also has additional features that make it a polished product, such as administrative capabilities.

JBoss AS 7 provides several administration channels: one of them is the new CLI, which contains many unique features that make it convenient for daily system administration and for monitoring application server resources.

The management tools also include a Web admin console, which offers an elegant view of the application server subsystems, allowing you to perform administrative tasks in a very simple way.

Within this chapter, we will thus describe the following instruments:

  • The Command Line Interface (CLI)
  • The Web admin console

Let’s start with the CLI that promises to be your next administrator’s Swiss army knife tool.

The Command Line Interface (CLI)

Terminals and consoles were one of the earliest types of communication interfaces between a system administrator and the machine. Due to this long time presence, most system administrators prefer to use the raw power of the command line for performing management tasks. One of the most evident advantages of using a low-level interface, such as a shell, is that tasks can often be executed as a part of batch processing or macros, for repetitive actions.

As we have introduced at the beginning of this book, the CLI is located in the JBOSS_HOME/bin folder and wrapped by jboss-admin.bat (Linux users, as well, will use the jboss-admin.sh equivalent).

By launching the shell script, you will start with a disconnected session. You can connect at any time with the connect [standalone/domain controller] command, which by default, connects to a server controller located at localhost on port 9999.

You are disconnected at the moment. Type ‘connect’ to connect to the server or ‘help’ for the list of supported commands. [disconnected /] connect Connected to standalone controller at localhost:9999

You can, at any time, adjust the default port where the native interface is running by finding this line into the standalone.xml/domain.xml configuration file:

<management-interfaces>   

<native-interface security-realm=”ManagementRealm”>       

<socket-binding native=”management-native”/>   

</native-interface>   

<http-interface security-realm=”ManagementRealm”>       

<socket-binding http=”management-http”/>   

</http-interface>  

</management-interfaces>    

<socket-binding-group name=”standard-sockets” default-interface=”public”>

. . . . . . .  

<socket-binding name=”management-native” interface=”management” port=”9999″/>

 <socket-binding name=”management-http” interface=”management” port=”9990″/>

. . . . . . .

</socket-binding-group>

As you can see from the above code snippet, the socket management alias are defined within the management-interfaces section, while the corresponding port is contained in the socket-binding section. A handy switch is –connect, which can be used to automatically hook up to your standalone/domain controller:

jboss-7.x.x.x/bin/jboss-admin.bat –connect

or on a Linux machine:

jboss-7.x.x.x/bin/jboss-admin.sh –connect

The corresponding command for exiting the CLI is quit, which closes the connection to the main
controller:

[standalone@localhost:9999 /] quit Closed connection to localhost:9999

How to use the CLI

One of the most interesting features of the CLI is its embedded intelligence, which helps us to find the correct spelling of resources and commands, by simply pressing the Tab key. You can even use it to find out the parameters needed for a particular command, without the need to go through the reference manual.

This will guide us into the first part of our journey, where we will learn the available commands. So, once you have successfully connected, press the Tab key, and it will expand to show the list of available commands and resources. Here’s the output of it:

Screenshot_4

As you can see, there are about 25 commands available. We can, however, distinguish all the interactions that happen with the CLI into two broad categories:

Operations: These include the resource path (address) on which they are executed.

Commands: These don’t include the resource path and they can, thus, execute an action independently from the path of the current resource.

Navigating through the resources and executing operations

As we said, operations are strictly bound to an application server resource path. The path along the tree of resources is represented by the “/” character, which, as it is, represents the root of the tree, just like for an Unix-Linux file system.

When you are executing operations on the AS resources, you have to use a well-defined syntax:

[node-type=node-name (,node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]

It looks a bit awkward at first glance, however, we will try to de-mystify it with the following example:

[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=2500) {“outcome” => “success”}

Here, we are telling the CLI to navigate into the deployment-scanner sub-system, under the default scanner resource, and set the scan-interval attribute to 2500 ms, using the write-attribute operation.

This example also shows the distinction between resources, attributes, and operations.

A resource is an element of the configuration that is located under a path. All elements, which are classified as resources, can be managed through the AS 7 interfaces. For example, the deployment-scanner is a resource located under the subsystem path. It has a children elements named default scanner. On the single resource, or on the child resources, you can invoke some operations, such as reading or writing the value of an attribute (the scan-interval).

Finally, notice that operations are introduced by the : prefix, while resources are introduced by the /character. Here’s a screenshot that helps to fix the basic terminology concepts:

Screenshot_5

In order to move through the resources path, you can either state the full tree path (as in the earlier example) or use the cd command or also the equivalent cn (change node) to navigate to the path and then issue the desired command. For example, the earlier attribute can also be rewritten as:

[standalone@localhost:9999 /] cd /subsystem=deployment-scanner/scanner=default

[standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=2500)

{“outcome” => “success”}

Tip

Does modified attributes survive server restart?

If you have been using the earlier JBoss’ jmx-console, that’s a question we would expect from you. As a matter of fact, most MBeans contacted by the jmx-console didn’t alter the server state permanently. When using CLI, every change is persisted into the server configuration file, thus, you must be responsible when you are using this instrument. More power asks more responsibility indeed! Nevertheless, you can, at any time, take a snapshot of your server configuration. See the section Taking snapshots of the configuration.

Just like for the operating system shell, by issuing cd .. you move the resource pointer to the parent resource:

[standalone@localhost:9999 scanner=default] cd ..

[standalone@localhost:9999 subsystem=deployment-scanner]

You can, at any time, check the resource path where you are located, by issuing either an empty cd command or just pwd, as you do for an Unix shell:

[standalone@localhost:9999 scanner=default] pwd /subsystem=deployment-scanner/scanner=default

Finally, in order to simplify your navigation, we’ll close this section, by giving a bird’s eye view of the AS tree or resources:
Screenshot_6

As you can see, the tree of resources includes eight child resources, each one handling one core aspect of the application server. In the Appendix of this book,

you will find a handy list of useful commands that can be used for your daily system administration. Most of the time, you will explore the sub-system resources, which contain all the application server core modules; other resources that you’ll want to learn more about are core-service, which handles management interfaces (such as the CLI itself), or the deployment resource, which can be used to manipulate deployed artifacts, or the socket-binding-group, which is the resource you will need to change the ports used by the application server.

Operations which you can issue on a resource

Having learnt the basics of navigation through the resources, let’s see the commands that can be issued on a resource. Operations are triggered by the : character— you can get a list of them by using the tab-completion feature (Tab key). Here’s a list of them:

Screenshot_7

Screenshot_8

Screenshot_9

The read-resource deserves some more explanation. As a matter of fact, without any extra arguments, it provides information about the resource’s attribute and the direct child nodes.

For example, here’s the resource scanning of the datasource sub-system, which includes the default datasource named ExampleDS.

[standalone@localhost:9999 /] /subsystem=datasources:read-resource() {

“outcome” => “success”,

“result” => {

“xa-data-source” => undefined,

“data-source” => {“java:jboss/datasources/ExampleDS” => undefined},

“jdbc-driver” => {“h2” => undefined}

}

}
You might have noticed the undefined attribute for some elements. As a matter of fact, the information provided by the read-resource command is limited to listing the name of child resources. If you want to read information about all child resources, including their corresponding attributes, you have to issue the command with the additional (recursive=true) parameter:

[standalone@localhost:9999 /] /subsystem=datasources:read-resource(recursive=true) {

“outcome” => “success”,   “result” => {

“xa-data-source” => undefined,

“data-source” => {“java:jboss/datasources/ExampleDS” => {

“background-validation” => undefined,

“background-validation-millis” => undefined,

“blocking-timeout-wait-millis” => undefined,

“connection-properties” => undefined,

“connection-url” => “jdbc:h2:mem:test;DB_CLOSE_DELAY=-1”,

“driver-name” => “h2”,

“enabled” => true,

 }

},

“jdbc-driver” => {“h2” => {

“driver-module-name” => “com.h2database.h2”,

 “driver-name” => “h2”,

 “driver-xa-datasource-class-name” => “org.h2.jdbcx.JdbcDataSource”

 }

}

}

As you can see, by adding the recursive=true parameter, the CLI has also included the list of configuration parameters, which are stored as children of the datasource element. For the sake of brevity, we have intentionally included just the first few datasource parameters.

Additionally, some resources can produce metrics, which are collected as runtime attributes. These attributes are not showed by default, unless you provide the include-runtime=true parameter. For example, the web sub-system typically collects some runtime attributes relative to the http connector metrics: [standalone@localhost:9999 connector=http] :read-resource(include-runtime=true) {

“outcome” => “success”,

“result” => {

“bytesReceived” => “0”,

“bytesSent” => “0”,

“enable-lookups” => false,

“enabled” => true,

“errorCount” => “0”,

“max-post-size” => 2097152,

 “max-save-post-size” => 4096,
“maxTime” => “0”,

“processingTime” => “0”,

 “protocol” => “HTTP/1.1”,

“redirect-port” => 8443,

“requestCount” => “0”,

“scheme” => “http”,

“secure” => false,

“socket-binding” => “http”,

 “ssl” => undefined,

“virtual-server” => undefined

}

}

If you want to learn more about a resource, including a short description about itself and its attributes, you can use the read-resource-description, which also includes the resource’s runtime attributes. The output can be quite verbose, so here we will just include the head section of it:

[standalone@localhost:9999

connector=http] :read-resource-description

:read-resource-description {

“outcome” => “success”,   “result” => {

“head-comment-allowed” => true,

“tail-comment-allowed” => true,

“type” => OBJECT,

“description” => “A web connector.”,

“attributes” => {       “name” => {

“type” => STRING,

 “description” => “A unique name for the connector.”,

“required” => true,

“nillable” => false,

 “access-type” => “read-only”,

 “storage” => “configuration”

}

}

}

} The read-operation-names and read-operation-description provide the list of available operations on a certain resource and their description. That would produce a synthetic information, just as we have added in the earlier table, so we will not rehash the description. Next, the read-children operations can be used to collect information about child nodes. The read-children-types provides information about the child resources and it’s pretty similar to a simple ls command. For example, on the root resource it would produce the following:

[standalone@localhost:9999 /] :read-children-types() {

“outcome” => “success”,

“result” => [

“extension”,

“core-service”,

“path”,

“subsystem”,

“system-property”,

“deployment”,

“interface”,

 “socket-binding-group”   ] }

The read-children-names delivers information about a single children resource and it’s pretty much the same as issuing a cd “resource” followed by an ls command. For example, supposing we want to know the list of deployed resources on the AS:

[standalone@localhost:9999 /] :read-children-names(child-type=deployment) {

“outcome” => “success”,

“result” => [

“Enterprise.ear”,
“EJB.jar”,

“Utility.jar”   ] }

Finally, the read-children-resources command returns information about a child node of a certain type, which needs to be provided as argument. This command is equivalent to executing a read-resource operation on each child resource. In the previous example, when issued on an hypothetic Enterprise.ear deployment resource, it will provide the sub-deployment information: [standalone@localhost:9999 deployment=Enterprise.ear] :read-children-resources(child-type=subdeployment) {

“outcome” => “success”,

“result” => {

“WebApp.war” => {

“subdeployment” => undefined,

“subsystem” => {“web” => undefined}

},

 “Utility.jar” => {

“subdeployment” => undefined,

“subsystem” => undefined

}

}

}

Optionally, you can also include as an argument include-runtime=true, to include runtime attributes, and recursive=true that provides information about all child resources recursively.

Executing commands with the CLI

As we said, the CLI includes a set of actions as well, which are not bound to your navigation path across the AS tree, but can be issued anywhere to create and modify resources.

For example, the version command can be issued to retrieve some basic information about the application server and the environment where JBoss AS is running:

[standalone@localhost:9999 /]

version JBoss Admin Command-line Interface

JBOSS_HOME: C:\jboss-as-7.1.0.Alpha1

JAVA_HOME: C:\Program

Files\Java\jdk1.6.0_24

java.version: 1.6.0_24

java.vm.vendor: Sun Microsystems

Inc. java.vm.version: 19.1-b02

os.name: Windows 7

os.version: 6.1

In most cases, commands are used as an alias for quickly creating some resources, such as JMS destinations and datasources.


0 Responses on Managing the Application Server"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.