•   17/12/2009 2:19 PM
•  
  • Java Application Servers (JBoss, Tomcat, Glas

---

Applicable Plans: Standard Max VPS, All Advanced VPS, all Premier VPS plans (CentOS 5 plans)

User Guide – GlassFish v3 User Guide

GlassFish is a free, open source application server which implements the newest features in the Java EE 6 platform. GlassFish v3 support includes JSP 2.2, JFS 2.0, Servlet 3.0, EJB 3.1 JAX-WAS 2.2 and offers many useful features. For details please visit the GlassFish Community Website.

Overview

The eApps Hosting service is designed to make it easy to use GlassFish v3 for serving Java EE applications in your Virtual Private Server (VPS). This User Guide is not intended as a reference source for GlassFish. See the Links to Other Information at the end of this document if you need detailed information about GlassFish.

This User Guide explains the basic setup of a GlassFish application on the eApps Hosting service. If you follow the guidelines explained in this User Guide you will remain safely inside the eApps Support envelope. If you choose to use a custom configuration that is outside of the guidelines contained in this document, you may be subject to service fees if you need assistance from the eApps Support department. If you have any questions about this User Guide please contact eApps Technical Support for assistance.

GlassFish is only available on plans using the CentOS 5 or greater operating system. To see what operating system (OS) you have, click on the Subscriptions icon from the My Account tab of your Control Panel. Then click on the name of the subscription you want to see. The OS for the subscription will be displayed near the top of the page. If you are not on a CentOS 5 plan, but would like information on updating your plan, please contact eApps Technical Support for more information.

GlassFish is not available in the Standard and Standard Plus plans due to memory requirements. The Standard Max plan has just enough memory to run GlassFish and serves as our entry level plan for GlassFish users. However, it is important that you select a plan that has enough memory for your application during peak usage.

If you do not need the advanced features of GlassFish, we recommend that you use a less resource intensive JSP/servlet container such as Tomcat. 

Requirements
 
How to Use GlassFish

Using the GlassFish Admin Console
 
Overview of three approaches for deployment

Apache as a front end to GlassFish using mod_jk  

Apache as a front end to GlassFish using mod_proxy_ajp
 
GlassFish Standalone (without Apache)  
 
Multiple Sites With GlassFish (Additional Virtual Servers)

The Asadmin Utility

Tuning GlassFish

Links to Other Information

---

Requirements

GlassFish v3 requires that Java 1.6 is installed. Depending on how you are going to deploy your GlassFish application, you may also need to install the mod_jk module for Apache.

If the Java Libraries are not currently installed, make certain to install them before installing Glassfish. The Glassfish startup will fail if a JVM is not installed. 

GlassFish

To use GlassFish you will have to install the GlassFish application and Java from the Control Panel.

Do not install both Tomcat and GlassFish because GlassFish has its own JSP/servlet component, and if you have both installed your environment will have conflicting port issues.

Java Libraries

Please install the Java-SE 6

mod_jk

mod_jk is an Apache module that serves as a front end to GlassFish. mod_jk allows you to pass requests for GlassFish through Apache on port 80.If you are going to use this approach with GlassFish, install mod_jk.

mod_proxy_ajp

mod_proxy_ajp is only available on CentOS 5 plans. Because it is an Apache module, it is added as part of the Apache application when GlassFish is installed.

To install an Application, follow these steps:
Login to your Control Panel, and click on the System Tab. If necessary, click the Select Another System (Subscription) link on the left and choose the correct Virtuozzo container.

Go to Applications, and click on the Add Application link. Select the box next to the Application(s) you want to install, and then scroll down and click the Next button.

This takes you back to the All Applications screen. Wait for five to ten minutes, then click on the Refresh link at the upper right, just under the word Parallels. The application should now show as installed. If it is still in a Scheduled state, wait another five minutes, and click Refresh again. If you see it in Error state, or it still shows as Scheduled, please contact eApps Technical Support.

---

How to Use GlassFish

In this User Guide, the domain of example.com is used as a placeholder. Please substitute your actual domain name for example.com where necessary.

All GlassFish configurations are done either through the administrative console at http://example.com:4848 or using the command line asadmin tool. We will focus on the minimum configurations required for using GlassFish. Please click on the Help button on the top right of the GlassFish Admin Console for details on advanced configurations.

If you are new to GlassFish it is highly recommended that you get a basic understanding of it's architecture. The architecture page at http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV2Architecture and the getting started section of the administration guide at http://docs.sun.com/app/docs/doc/819-3671 will help you get a understanding of how things are structured.

This User Guide is only intended to introduce you to the basics of how to install and configure GlassFish in the eApps Hosting environment. For more detailed explanations of GlassFish configuration and setup, please refer to the official GlassFish documentation and the GlassFish community.

How GlassFish handles requests

The first thing to understand is how GlassFish maps a request to a given application. GlassFish uses domains (an administrative area), instances, virtual servers, hosts (the domain names or IP addresses which to serve a applications for) and web modules (applications that are deployed) to determine what application to serve.
Upon installation, there is a domain (domain1), an instance (server), a virtual server (server) is created and the hostname of the VPS is set by default as a host to serve applications.

Please note that the term domain as it's related to GlassFish is not to be confused with a domain name as in DNS domains. A domain in GlassFish is an instance of a single application server installation.

Instead of another installation of GlassFish (which would be required when using Tomcat or JBoss) you can simply create multiple domains (administrative domains) each with its own administration settings for serving applications totally separate from the other domains. Each domain will need a set of ports to bind on for its service. Since the standard ports are taken by the default domain (domain1) different port numbers must be assigned. You must use the asadmin command line tool to create a domain. An example is given in The Asadmin Utility section of this documentation. Please see the official GlassFish documentation for more information.

Starting and stopping GlassFish

GlassFish can be stopped, started or restarted from the command line or the Control Panel, or by using the command line asadmin tool.

These commands will start, stop or restart ALL administrative domains and instances.

Command line

The following must be done from the command line of the VPS while logged in via SSH, as the root user.

[root@example ~]# service glassfish start Starting GlassFish Application Server [ OK ] [root@example ~]# [root@example ~]# service glassfish stop Stopping GlassFish Application Server [ OK ] [root@example ~]# [root@example ~]# service glassfish restart Stopping GlassFish Application Server [ OK ] Starting GlassFish Application Server [ OK ] [root@example ~]# [root@example ~]# service glassfish status GlassFish Application Server is running [root@example ~]#

Control Panel

Login to your Control Panel, and click on the System Tab. If necessary, click the Select Another System (Subscription) link on the left and choose the correct Virtuozzo container.

Go to Applications, and either click on the All Applications link and then the GlassFishv3 link, or click directly on the application link for GlassFishv3. There will be a radio button to either Stop or Start GlassFish, depending on its current status.

GlassFish can also be stopped or started from the Services link on the System Tab. Click on the link for GlassFish, and there will be a radio button to Stop or Start GlassFish, depending on its current status.

If you have multiple administrative domains running and want to control a single domain please use the asadmin tool as shown below.

[root@example ~]# su – gfish -bash-3.2$ -bash-3.2$ asadmin stop-domain domain1 Domain domain1 stopped. -bash-3.2$ -bash-3.2$ asadmin start-domain domain1 Starting Domain domain1, please wait. Default Log location is /opt/glassfish/domains/domain1/logs/server.log. Redirecting output to /opt/glassfish/domains/domain1/logs/server.log Domain domain1 started. Domain [domain1] is running [Sun GlassFish Enterprise Server v2.1 (9.1.1) (build b60e-fcs)] with its configuration and logs at: [/opt/glassfish/domains]. Admin Console is available at [http://localhost:4848]. Use the same port [4848] for "asadmin" commands. User web applications are available at these URLs: [http://localhost:8080 https://localhost:8181 ]. Following web-contexts are available: [/web1 /__wstx-services ]. Standard JMX Clients (like JConsole) can connect to JMXServiceURL: [service:jmx:rmi:///jndi/rmi://example.virtual.vps-host.net:8686/jmxrmi] for domain management purposes. Domain listens on at least following ports for connections: [8080 8181 4848 3700 3820 3920 8686 ]. Domain supports application server clusters and other standalone instances. -bash-3.2$

---

Using the GlassFish Admin Console

The login details for the GlassFish Admin Console are located in the Control Panel, System Tab, Applications, GlassFish.

Here you will find the Control Panel URL, which is the URL for the GlassFish Admin Console. The Default Login details are also provided.

Read the section about Changing the Admin Console password carefully. If you try to change the password for the GlassFish Admin Console in any other manner, GlassFish will refuse to start, and the only option will be to uninstall and reinstall GlassFish, and deploy your applications again.

Logging in to the GlassFish Admin Console

To connect to the GlassFish Admin Console, click on the Control Panel URL and then login using the correct User Name and Password. You can also use the GlassFish Admin Console URL of http://example.com:4848


GlassFish Admin Console login screen


GlassFish Admin Console Main Screen

Deploying applications using the GlassFish Admin Console

To deploy your application using the GlassFish Admin Console, follow the steps below. These steps will work for any of the eApps supported methods for deploying GlassFish applications.

The navigation menus in the GlassFish Admin Console can collapse and expand depending on the context. Please take a few moments as you move around the Admin Console to familiarize yourself with all the options.

Login to the GlassFish Admin Console

The URL for the GlassFish Admin Console is http://example.com:4848

The User Name and Password are found in the Control Panel, System Tab, Applications – GlassFish. If you have changed the GlassFish Admin Console password, make sure to use the new password.

Deploying GlassFish Applications, step by step

From the main GlassFish Admin Console screen, click on the Applications menu in the Common Tasks pane on the left, and then click on Web Applications.
In Web Applications, click on Deploy – this takes you to the Deploy Enterprise Applications/Modules screen.



1. Location – this is the location, either on the client machine or the server, of the Enterprise Application to deploy.

• Packaged file to be uploaded to the server – this is a file located on the client computer. Click Browse to find the file on the local computer to upload.
• Local packaged file or directory that is accessible from the Application Server – this is a file located on the same server where the GlassFish application server is running. Browse Files allows you to look for a file in the current directory, Browse Folders allows you to look through the file system of the server for the file to upload to GlassFish. You can also type in the full path to the file. This option will allow you to deploy an un-packaged application from an exploded directory. This type of deployment is for advanced developers, and should not be used in production environments. eApps does not support deploying from an exploded directory.

2. Type – using the drop down menu, choose from

• Web Application (.war)
• Enterprise Application (.ear)
• Connector Module (.rar)
• Ejb Module (.jar)
• App Client (.jar)
• Ruby Application
  

Depending on the Type of application chosen, some of the options offered change. The default Web Application (.war) shows most of the available options, so that will be used as the example. If you need more information on the other Types available, click on the context sensitive Help button at the top right of the screen.

3. Context Root – this is a string that identifies the application. In the URL for a Web Application, the Context Root immediately follows the port number (http://host:port/context-root/...). The Context Root takes the same name as the Application Name, and can be changed to match.

4. Application Name – a unique name for the application. If the application is uploaded using the GlassFish Admin Console, the name will be the file name, minus the file extension. For example, if you uploaded hello.war, the Application name would be hello. You can name the application anything you want, as long as the name is unique.

5. Virtual Servers – if you have created additional Virtual Servers, there will also be a Virtual Servers field, where you can select which Virtual Server to use for the application.

6. Status – by default, an application is available as soon as it is deployed. To disable the application so that it is unavailable after Deploy Enterprise Applications/Modules page, uncheck the Enabled checkbox.

7. Precompile JSPs – check this ON to precompile the JSP pages. If this is checked OFF, the JSP pages are compiled at runtime, which can result in a performance hit for production environments.

8. Run Verifier – this verifies the structure and contents of the file. Be aware that verification of large files can be quite time consuming and resource intensive. Only check this ON if you suspect the file to be corrupt or non-portable.

9. Force Redeploy - If the application is already deployed the option forces redeployment.

10. Libraries – a list of JAR files for the application. The libraries must be accessible on the server.

11. Description – a brief description for this application (optional).

Java Web Start – if you are using Enterprise Application (.ear) or App Client (.jar), you will have the option for Java Web Start. Java Web Start provides browser-independent Deploy Enterprise Applications/Modules page of Java client applications that run directly in a Java VM. 

Click OK to deploy the application.

Confirm Virtual Server configuration to serve this application

Click on the Home link at the top left of the GlassFish Admin Console, to go back to the Common Tasks screen.

In the Common Tasks navigation pane on the left, click on Configurations, which expands to show the server configurations. By default, there are two choices: default-config and server-config.

Click on server-config to expand the menu, and then click on HTTP Service. This expands to show HTTP Listeners and Virtual Servers. Click on Virtual Servers, and choose the server. By default, there are two choices: server and __asadmin. Click on server. If you have created a new Virtual Server that you used for this application, chose that server instead.


Edit Virtual Server screen

1. ID – this is the name of the virtual server for internal use. This name is not shown to HTTP clients. The default virtual server is named server, and for the default server that name cannot be changed.

2. Hosts – this is the list all the domain names for this virtual server and application. If you are serving applications from example.com and www.example.com, both names have to be in this field.

For the default virtual server there will be a value of ${com.sun.aas.hostName}, which is a variable that holds the hostname of the VPS. If the hostname is one of the domains you want for this virtual server, leave this in place. This variable can be removed if you are not serving applications from the hostname of the VPS.

3. State – select the State for the application. The default is ON.

4. SSO (Single Sign On) – Specifies whether single sign-on behavior is inherited from the HTTP Service, enabled, or disabled. By default, it is inherited from the HTTP Service. If this option is enabled, single sign-on is enabled for web applications on this virtual server that are configured for the same realm. If this option is disabled, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server.

5. Network Listeners – this field is automatically populated with the HTTP Listeners for this virtual hosts. The defaults are http-listener-1 which provides http support, and http-listener-2 which provides https support.

6. Default Web Module – choose the deployed web module (if any) that will respond to any requests that cannot be mapped to other web modules deployed on the virtual server.

• If your application is being deployed at example.com/webapp, leave this field empty.
• If your application is being deployed at example.com, choose the name of the deployed application from the drop down list.

7. Log File – this is the path to the file for the virtual server logs. Leave this field empty to use the default server log of domain-dir/logs/server.log

8. docroot – this is the absolute path to the DocumentRoot directory for the server. The default location is domain-dir/docroot. The contents of the docroot will be served if the virtual server is accessed at example.com, but there is no Default Web Module set. Since the URL will either be example.com/webapp or example.com with a Default Web Module set, there is no need to change this value.

9. Access Logging – choose the method for access logging. By default, HTTP Service is checked.

11. Directory – the absolute path to the access log, by default the access logs are written to domain-dir/logs/access

---

Overview of three approaches for deployment

Your eApps Virtual Private Server (VPS) includes the Apache web server as part of the base environment. Apache is designed to serve static content, perl scripts, php scripts, and other types of content that requires a web server. GlassFish is designed primarily to serve Java EE applications.

One of the decisions you will need to make when deploying your GlassFish application relates to how you want GlassFish and Apache to interact. In most cases you will want to use Apache as a front end to GlassFish. In rare cases you may want to run GlassFish without Apache. This section explains three approaches for your deployment.

eApps Hosting supports three approaches to deploy your GlassFish application. Before you proceed you will need to determine which of the three approaches below is appropriate for you.

• Apache as a front end to GlassFish using mod_jk - this approach allows you to control what content is served by GlassFish and what content (if any) is served by the Apache web server. You will need to specify directives that tell Apache what content to pass on to GlassFish. mod_jk is mature, widely used, and also has advanced features for load balancing and other techniques. The majority of eApps customers use this approach.

• Apache as a front end to GlassFish using mod_proxy_ajp - this approach is similar to mod_jk but is simpler to use and allows you to take better advantage of Apache's capabilities, such as mod_rewrite. It provides features for load balancing as well, but is not as sophisticated as mod_jk.

• GlassFish standalone (without Apache) - this approach allows you to run GlassFish without Apache. GlassFish has a built in web server so Apache is not strictly needed. Since all requests are directed to GlassFish, it theoretically is more efficient than approaches that use Apache as a front end, although the difference is not meaningful for most deployments.

---

Apache as a front end to GlassFish using mod_jk

Apache runs securely on port 80. GlassFish runs securely on port 8080, which means that the default URL of your application will be http://example.com:8080/ or http://example.com:8080/mywebapp

With mod_jk, you will be able to run GlassFish securely on it's normal port and have Apache forward requests to GlassFish. This will eliminate the 8080 from the URL.

When mod_jk is installed, default directives are created in /etc/httpd/conf.d/mod_jk.conf or in /etc/httpd/conf/httpd.conf depending on the version of mod_jk installed.

These are the default mod_jk directives:

JkMount /*.jsp ajp13
JkMount /*.do ajp13
JkMount /manager* ajp13
JkMount /admin* ajp13
JkMount /web-console* ajp13

All other mod_jk directives must be added to the Custom Settings tab for the site using the Control Panel. Editing the Apache config file manually will cause problems. The Apache User Guide has more information on this – please see this section and this section for more details.

mod_jk also offers no-jk directives, which allow requests for certain applications, such as Open Webmail or Awstats to bypass GlassFish so they can be served directly by Apache. The no-jk directives are also added to the Custom Settings tab for each site. Examples of no-jk directives are given as part of the mod_jk examples.

mod_jk syntax overview

The standard format for a mod_jk directive is:
JkMount /servlet/* ajp13

• JkMount – this is the JkMount directive that calls mod_jk
• /servlet/* - this is the regular expression(regex) that is matched in the referring URL and is passed to the servlet container. Typically, this is the only part of a JkMount directive you will change
• ajp13 – this is the internal handler that will receive the request. Unless you are a very advanced user you will never change this part of the directive. eApps only supports the ajp13 handler.

The above directive will pass all URLs with a suffix of /servlet/ to the ajp13 handler and the request will be handled by GlassFish. A URL with a suffix of /mail will still be handled by Apache.

Examples using mod_jk

Deployment with GlassFish serving JSP and Servlets, Apache serving all other content at example.com/mywebapp

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://example.com/mywebapp or http://www.example.com/mywebapp with Apache serving other applications provided by eApps.

Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. If you have not yet done so, read the entire Using the GlassFish Admin Console section of this User Guide.

mod_jk directives - in this example Apache will serve all applications provided by eApps but forward requests to /mywebapp to GlassFish. Add the line below to your Custom Settings.

JkMount /mywebapp* ajp13

Deployment with GlassFish serving JSP and Servlets , Apache serving all other content at example.com

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://example.com/ or http://www.example.com/ with Apache serving other applications provided by eApps.

Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. If you have not yet done so, read the entire Using the GlassFish Admin Console section of this User Guide.

mod_jk directives - in this example Apache will serve all applications provided by eApps but forward all other requests to GlassFish. Add the lines below to your Custom Settings.

JkMount /* ajp13

# Directives to enable Apache to continue serving applications dependent on it.
SetEnvIf Request_URI "/webmail*" no-jk
SetEnvIf Request_URI "/mail*" no-jk
SetEnvIf Request_URI "/awstats*" no-jk
SetEnvIf Request_URI "/myadmin*" no-jk
SetEnvIf Request_URI "/pgadmin*" no-jk
SetEnvIf Request_URI "/cgi-bin*" no-jk
SetEnvIf Request_URI "/openwebmail*" no-jk
SetEnvIf Request_URI "/joomla*" no-jk
SetEnvIf Request_URI "/wordpress*" no-jk
SetEnvIf Request_URI "/drupal*" no-jk
SetEnvIf Request_URI "/mailman*" no-jk
SetEnvIf Request_URI "/spamassassin*" no-jk

---

Apache as a front end to GlassFish using mod_proxy_ajp

mod_proxy_ajp is an extension of the mod_proxy module that is available in Apache 2.2. The required modules are installed automatically if you have GlassFish installed and have an eApps VPS running the CentOS 5 operating system or higher version.

All mod_proxy_ajp directives must be added to the Custom Settings tab for the site using the Control Panel. Editing the Apache config file manually will cause problems. The Apache User Guide has more information on this – please see this section and this section for more details.

Examples using mod_proxy_ajp

Deployment with GlassFish serving JSP and Servlets, Apache serving all other content at example.com/mywebapp

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://example.com/mywebapp or http://www.example.com/mywebapp with Apache serving other applications provided by eApps.

Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. If you have not yet done so, read the entire Using the GlassFish Admin Console section of this User Guide.

mod_proxy_ajp directives - in this example Apache will serve all applications provided by eApps but forward request to /mywebapp to GlassFish. Add the line below to your Custom Settings.

ProxyPass /mywebapp ajp://localhost:8009

Deployment with GlassFish serving JSP and Servlets, Apache serving all other content at example.com

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://example.com/ or http://www.example.com/ with Apache serving other applications provided by eApps.

Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. If you have not yet done so, read the entire Using the GlassFish Admin Console section of this User Guide.

mod_proxy_ajp directives - in this example Apache will serve all applications provided by eApps but forward request to / to GlassFish. Add the lines below to your Custom Settings.

# Directives for eApps applications dependent on Apache
ProxyPass /webmail !
ProxyPass /mail !
ProxyPass /joomla !
ProxyPass /awstats !
ProxyPass /myadmin !
ProxyPass /cgi-bin !
ProxyPass /pgadmin !
ProxyPass /openwebmail !

# Directives for your application
ProxyPass / ajp://localhost:8009
ProxyPassReverse / ajp://localhost:8009

---

GlassFish Standalone (without Apache)

GlassFish includes its own web server, so Apache is not technically needed. It is possible to run GlassFish without Apache.

Some important information about using GlassFish in standalone mode:
The only time this approach is useful is when you are running a commercial or open-source application and the developers of that application have specifically recommended this approach. In other words, the application was purpose built from the ground up to run using GlassFish in stand alone mode, without Apache.

This approach is best suited when the VPS is only going to be used to run this application, and nothing else. This is because any of the applications that rely on Apache and PHP, such as any of the web mail applications, or Awstats, or phpMyAdmin, etc, will not be available.

This approach is for users who are very familiar with GlassFish and Linux server configuration. Most users will see no benefit by using this approach.

How to set up GlassFish to run in standalone mode

GlassFish cannot run on port 80 because root privileges are required. Since GlassFish does not have the ability to start as root, bind to port 80, then switch back to a user without administrative privileges it would have to run as root. This creates a security issue for your system.

For the GlassFish standalone approach we use xinetd to keep GlassFish running on port 8080 and have requests to port 80 redirected to GlassFish. This requires us to disable Apache

Do not uninstall Apache! Apache is part of the base environment of your VPS on the eApps Hosting service. The examples explain how to disable Apache. Certain system events will synchronize your VPS to the standard base configuration and will automatically re-install Apache without your knowledge.

Stop and Disable Apache

Using the Control Panel
Login to your Control Panel, and click on the System Tab. If necessary, click the Select Another System (Subscription) link on the left and choose the correct Virtuozzo container.

Click on Service Management, and then Services. Click on the httpd service, and click on Stop and then Autostart Off. This stops the httpd (Apache) service, which stops the web server. This also stops httpd from starting again when the VPS is rebooted.

Using the Command line

The following must be done from the command line of the VPS while logged in via SSH as the root user. Do not edit these files from the Control Panel.

[root@example]# service httpd stop Stopping httpd: [ OK ] [root@example]# [root@example]# chkconfig httpd off

Add the port 80 redirect

[root@example ~]# cd /etc/xinetd.d [root@example xinetd.d]# vi glassfish

Using a text editor (in this example the vi editor) create a new file called glassfish with these lines:

# Redirects any requests on port 80 # to port 8080 (where GlassFish is listening) service http { socket_type = stream user = root wait = no redirect = localhost 8080 disable = no }

Restart xinetd for the changes to take effect.

[root@example xinetd.d]# service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] [root@example xinetd.d]#

Deployment with GlassFish serving JSP and Servlets, at example.com

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://example.com/ or http://www.example.com/

Since Apache will not be running, none of the apps normally served by Apache, such as Awstats or Open Webmail, will be available.

Deploy your applications using the steps from the Deploying applications using the GlassFish Admin Console section of this User Guide. If you have not yet done so, read the entire Using the GlassFish Admin Console section of this User Guide.

---

Multiple Sites With GlassFish (Additional Virtual Servers)

GlassFish has a default domain (domain1) instance (server) virtual server (server). To have multiple site functionality and host multiple applications on different domain names you must create addition virtual servers and apply one of the deployment approaches above. Since multiple virtual servers can exist inside of a GlassFish "domain" you can add additional virtual servers to domain1.

Login to the GlassFish Admin Console. See the Logging in to the GlassFish Admin Console section of this User Guide for more information if necessary.

If you are already logged in to the GlassFish Admin Console, click on the Home link at the top left of the GlassFish Admin Console, to go back to the Common Tasks screen.

In the Common Tasks navigation pane on the left, click on Configurations, which expands to show the server configurations. By default, there are two choices: default-config and server-config.

Click on server-config to expand the menu, and then click on HTTP Service. This expands to show HTTP Listeners and Virtual Servers. Click on Virtual Servers, and then click on New.


New Virtual Server screen

1. ID – this is the value that identifies the virtual server internally, and is not exposed to HTTP clients. This value can be any unique name.

2. Hosts – this is the list of domain names for this virtual server in a comma separated list. If you want the applications on this virtual server to be available at example.com and www.example.com, put both host names in this list.

3. State – select the State for the virtual server. The default is ON.

4. SSO (Single Sign On) – Specifies whether single sign-on behavior is inherited from the HTTP Service, enabled, or disabled. By default, it is inherited from the HTTP Service. If this option is enabled, single sign-on is enabled for web applications on this virtual server that are configured for the same realm. If this option is disabled, single sign-on is disabled for this virtual server, and users must authenticate separately to every application on the virtual server.

5. Network Listeners – use the default listeners of http-listener-1 and http-listener-2, to provide http and https support.

7. Default Web Module – this is the deployed web module that is used to respond to all requests that come in to any of the specified Hosts. This may be left blank if the application has not been deployed. This can be modified when an application is deployed.

8. Log File – enter the path of the file where the logging messages from this virtual server will go. Leave this field as is to send the logging messages to the default server log of domain-dir/logs/server.log.

9. docroot – this is the absolute path to the DocumentRoot directory for the server. The default location is domain-dir/docroot. The contents of the docroot will be served if the virtual server is accessed at example.com, but there is no Default Web Module set.

10. Access Logging – choose the method for access logging. By default, HTTP Service is checked.

11. Directory – the absolute path to the access log, by default the access logs are written to domain-dir/logs/access

---

The Asadmin Utility

The asadmin utility is the command line tool for making changes and adding configurations to GlassFish. In this section we will cover some of the basic asadmin tasks. Please see the asadmin documentation for advanced usage.

Since the GlassFish server is running as the gfish user it is recommended that the commands below are executed as the gfish user. In the event files need to be written we want the gfish user to have ownership.

Create a domain (administrative domain)

[root@example]# su - gfish -bash-3.2$ -bash-3.2$ asadmin create-domain --user admin1 --portbase 9000 --savelogin=true domain2 Please enter the admin password> passwd Please enter the admin password again> passwd Please enter the master password [Enter to accept the default]:> Please enter the master password again [Enter to accept the default]:> Using port 9048 for Admin. Using port 9080 for HTTP Instance. Using port 9076 for JMS. Using port 9037 for IIOP. Using port 9081 for HTTP_SSL. Using port 9038 for IIOP_SSL. Using port 9039 for IIOP_MUTUALAUTH. Using port 9086 for JMX_ADMIN. Domain being created with profile:cluster, as specified by variable AS_ADMIN_PROFILE in configuration file. Security Store uses: JKS Domain domain2 created. Login information relevant to admin user name [admin1] for this domain [domain2] stored at [/opt/glassfish/.asadminpass] successfully.

Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage this domain.

The --portbase of the ports selected above are not open the eApps network. You will have to subscribe to the eApps Custom Firewall service to open them up. Alternatively you can select a group of our open ports and execute the command above a bit differently.

asadmin create-domain --user admin2 --adminport port_number --savelogin=true domain2

Contact eApps Technical Support for the available ports list. Due to security reasons, this list is not publicly available.

After the command above you can login to the GlassFish Admin Console and add/modify the ports for the other service.

Starting the new domain

[root@example]# su - gfish -bash-3.2$ -bash-3.2$ asadmin start-domain domain2 Starting Domain domain2, please wait. Log redirected to /opt/glassfish/domains/domain2/logs/server.log. Redirecting output to /opt/glassfish/domains/domain2/logs/server.log Domain domain2 started. Domain [domain2] is running [Sun Java System Application Server 9.1_01 (build b09d-fcs)] with its configuration and logs at: [/opt/glassfish/domains]. Admin Console is available at [http://localhost:9048]. Use the same port [9048] for "asadmin" commands. User web applications are available at these URLs: [http://localhost:9080 https://localhost:9081 ]. Following web-contexts are available: [/web1 /__wstx-services ]. Standard JMX Clients (like JConsole) can connect to JMXServiceURL: [service:jmx:rmi:///jndi/rmi://glassfish.development.eapps.com:9086/jmxrmi] for domain management purposes. Domain listens on at least following ports for connections: [9080 9081 9048 9037 9038 9039 9086 ]. Domain supports application server clusters and other standalone instances. -bash-3.2$

Create a second virtual server for the domain

[root@example]# su - gfish -bash-3.2$ -bash-3.2$ asadmin create-virtual-server --port 9048 --user admin1 --hosts example.com,www.example.com --httplisteners http-listener-1,http-listener-2 vserver2 (this command should all be on one line) Command create-virtual-server executed successfully. -bash-3.2$

Deploy an application to vserver2 in domain2

[root@example]# su - gfish -bash-3.2$ -bash-3.2$ asadmin deploy --port 9048 --virtualservers vserver2 /tmp/hello.war Command deploy executed successfully. -bash-3.2$

The WAR file can actually be located anywhere on the system. Make sure that you specify the absolute path to the file in the command.

Stop domain2

[root@example]# su - gfish -bash-3.2$ -bash-3.2$ asadmin stop-domain domain2 Domain domain2 stopped -bash-3.2$

---

Tuning GlassFish

Java Heap Settings – an overview

The most important part of tuning GlassFish for better performance is to optimize the Java Heap settings. The Java Heap size is the amount of memory allocated to the Java Virtual Machine (JVM). The heap is where Java objects live, and there must be enough memory allocated to the JVM to support the needs of the deployed GlassFish applications.

The most common issue with GlassFish, by far, is a lack of available resources. In many cases, this is due to the Java Heap size either not being configured at all, or not being configured correctly. In other cases, the VPS is simply too small for the type of application being run on it. For example, while it is possible to run GlassFish on the Standard Max plan, that plan does not have the resources for a true enterprise application or a site that receives a high volume of traffic.

How to find the correct Java Heap settings

By default GlassFish is configured to use a maximum of 128 MB of RAM allocated to the heap. This setting will have to be changed in order to correctly optimize GlassFish.

To find the correct heap size , you will have to stop GlassFish, and use the Linux free command to see the available memory, and then multiple that value by two, and then subtract that result from the total RAM available for your plan.

This number will be roughly what you need to set for the maximum heap size.

The following must be done from the command line of the VPS while logged in via SSH, as the root user.

[root@example ~]# service glassfish stop Stopping GlassFish Application Server [ OK ] [root@example ~]# [root@example]# free -m total used free shared buffers cached Mem: 800 250 550 0 0 0 -/+ buffers/cache: 250 550 Swap: 0 0 0 [root@example]#

In this example, with GlassFish stopped, the VPS plus all other applications and services running consume 250 MB of RAM.

Multiply this value by two giving a total of 500, and subtract that from the total available RAM on the VPS for a value of 300 MB for the maximum heap.
Remember, this is just a rough estimate. You may find that you need to adjust this number up or down as necessary, depending on how your application is configured and what other services your VPS is running.

Generally, the maximum heap size should be just under half the amount of memory available to your VPS. You can of course adjust this value higher or lower, but you may have to experiment to determine the true optimum heap size. See the chart below for the eApps recommendations for the maximum heap size broken down by Plan.

If you run out of heap space, you might see the java.lang.OutOfMemoryError in your /opt/glassfish/domains/domain/logs/jvm.log

Plan	Allocated Memory for Plan	Max Java Heap Size (do not exceed)
Standard Max	432 MB	192 MB
Advanced	800 MB	384 MB
Advanced Plus	1200 MB	576 MB
Advanced Max	1600 MB	768 MB
Premier	2048 MB	960 MB
Premier Plus	2560 MB	1152 MB
Premier Max	4096 MB	1700 MB
Dedicated Servers	start with the 'total memory - (free memory x 2)' formula and adjust as needed

Adjusting the Heap settings

To adjust the Heap settings in Glassfish, log in to the GlassFish Admin Console. In the Common Tasks pane on the left, click on Configurations, then select the instance to configure. The default is server-config. Then click on JVM Settings. Click on the JVM Options tab at the top of the screen.

The default heap size is shown as:

-Xmx128m

Change that to the heap setting you need, and click Save.

PermGen setting

This screen also allows you to change the PermGen setting: look for -XX:MaxPermSize=128m setting. However, only change that if you are very sure as to the value you need.

Restart GlassFish from either method listed in Starting and stopping GlassFish section of this User Guide.

---

Links to Other Information

GlassFish Home Page - https://glassfish.dev.java.net
GlassFish wiki - http://wiki.glassfish.java.net
Apache 2.2 Documentation - http://httpd.apache.org/docs/2.2/
Mod_jk Home Page - http://tomcat.apache.org/connectors-doc/
eApps mod_proxy User Guide - http://support.eapps.com/hsp/mod_proxy_balancer
eApps Apache User Guide - http://support.eapps.com/hsp/apache
eApps Apache ANT User Guide - http://support.eapps.com/hsp/ant
eApps Apache Derby User Guide - http://support.eapps.com/hsp/derby
Please login to comment