USA +1(770)448 2100 | UK +44(0)20 81336940

 
Cloud Hosting Applications - GlassFish v3.0
Posted by Alan Bowman on 03 October 2010 04:13 PM

Applicable Plans - eApps Cloud Hosting Plans (eApps templates only)

User Guide - GlassFish v3

Overview

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 - http://java.sun.com/javaee/community/glassfish/

The eApps Hosting service is designed to make it easy to use GlassFish v3 for serving Java EE applications in your Virtual Machine. 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 Cloud 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.

Pay careful attention to the size of your offering if you are deploying GlassFish applications. GlassFish is very memory intensive. For a small GlassFish application, start with at least 768 MB of RAM, and be prepared to scale upwards.

NOTE - the domain name of eapps-example.com is used as the example domain throughout this User Guide. Please substitute your actual domain name as necessary.

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.

Prerequisites

How to Use GlassFish
How GlassFish handles requests
Starting and stopping GlassFish

Using the GlassFish Administration Console
Logging in to the GlassFish Administration (Admin) Console
Deploying applications using the GlassFish Admin Console

Overview of three approaches for deployment

Apache as a front end to GlassFish using modjk
Examples using mod
jk

Apache as a front end to GlassFish using mod_proxy_ajp
Examples using mod_proxy_ajp

GlassFish Standalone (without Apache)
How to set up GlassFish to run in standalone mode
Deployment with GlassFish serving JSP and Servlets, at eapps-example.com

Multiple Sites With GlassFish (Additional Virtual Servers)

The Asadmin Utility

Tuning GlassFish
Java Heap Settings – an overview
Adjusting the Heap settings

Links to other information


Prerequisites

GlassFish v3 requires that Java SE 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.

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.

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 using mod_jk as for Apache to serve as your front-end for GlassFish, you will need to install the mod_jk application.

If you are going to use mod_proxy_ajp, you will not need to install anything because it is an Apache module, and part of the Apache base install.

Instructions on how to install and manage applications are in the User Guide - Installing and Managing Applications in the Control Panel http://support.eapps.com/control_panel_eapps/app_management

With either the mod_jk or mod_proxy_ajp approach, you will also need to set up a virtual host in Apache. See the User Guide - Creating Websites - http://support.eapps.com/control_panel_eapps/webserver for more information.


How to Use GlassFish

Remember to substitute your domain name for eapps-example.com as necessary.

All GlassFish configurations are done either through the administrative console at http://eapps-example.com:4848 or using the command line asadmin tool. This User Guide 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 how GlassFish works, and how all the components interact. The official GlassFish Community is a good starting point - http://glassfish.java.net/.

NOTE - 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 VM 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.

NOTE - 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 Virtual Machine 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 menu > Service Management. Scroll down to the glassfish service, mark the checkbox to the left and scroll to the bottom of the page and click on the desired action (Start|Stop|Restart).

Asadmin tool (command line only)

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 Administration Console

Logging in to the GlassFish Administration (Admin) Console

You can login to the GlassFish Admin Console URL of http://eapps-example.com:4848 or http://IP_Address:4848. The default login and password is listed in the information for this application in the Control Panel. Go to Applications, and click on GlassFish Server v3. The ADMINUSER and PASSWORD are in the Description line.

The first time you try to access the GlassFish Admin Console, the software has to install some components and initialize some system functions. It may take 5 to 8 minutes (possibly more, depending on your available system resources) for the GlassFish Admin Console to show in the browser. Please be patient.

GlassFish v3 Admin Login Screen

After you log in to the Admin Console, you see the main screen for GlassFish.

GlassFish v3 Admin 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.

NOTE - 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.

Deploying GlassFish Applications

Login to the GlassFish Admin Console and 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.

GlassFish v3 Admin Deploy 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.

GlassFish v3 Edit Virtual Server

  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 eapps-example.com and www.eapps-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 Virtual Machine. 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 Virtual Machine.

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

  2. 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.

  3. 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.

  4. 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 eapps-example.com/webapp, leave this field empty.
    • If your application is being deployed at eapps-example.com, choose the name of the deployed application from the drop down list.
  5. 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

  6. 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 eapps-example.com, but there is no Default Web Module set. Since the URL will either be eapps-example.com/webapp or eapps-example.com with a Default Web Module set, there is no need to change this value.

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

  8. 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 Virtual Machine 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.

One major shortcoming of using GlassFish standalone is that the eApps Hosting service uses the Apache web server to serve all web based applications such as Web mail, PHP applications, etc. Running GlassFish standalone results in these applications being unavailable to you, by default, in your eApps Cloud server.

This approach is generally used when deploying a commercial or open source application for a specific purpose and that is all that the server is intended to be used for.


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://eapps-example.com:8080/ or http://eapps-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

You must also specify mod_jk directives for your application in the Edit Directives option for each Virtual Server you create that uses GlassFish. Edit Directives is found in the Control Panel, Apache Webserver - click on the icon for the Virtual Server you wish to edit, and then on the Edit Directives module.

If you are comfortable working with the Apache httpd.conf configuration file directly, you can also add in your mod_jk directives to the VirtualHost block for the web site using either the File Manager or the command line. The web server will need to be restarted after the changes have been made.

mod_jk also offers no-jk directives, which allow requests for certain applications, such as SquirrelMail or Awstats to bypass GlassFish so they can be served directly by Apache. The no-jk directives are added in the same way as the mod_jk directives. Examples of no-jk directives are given as part of the mod_jk examples in the deployment examples that follow.

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 eapps-example.com/mywebapp

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/mywebapp or http://www.eapps-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 Edit Directives:

JkMount /mywebapp* ajp13

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

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-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, because mod_proxy_ajp is part of the Apache 2.2 web server.

As with mod_jk, the mod_proxy_ajp directives must be specified in the VirtualHost block for each site, either from the command line, the Edit Directives option in the Virtual Server, or the File Manager in the Control Panel.

Examples using mod_proxy_ajp

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

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/mywebapp or http://www.eapps-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 following mod_proxy_ajp directive in the Edit Directives module for this Virtual Server. Edit Directives is found in the Control Panel, Apache Webserver - click on the icon for the Virtual Server you wish to edit, and then on the Edit Directives module. You can also add these lines to the correct VirtualHost block in the httpd.conf file using the File Manager, or from the command line.

ProxyPass /mywebapp ajp://localhost:8009

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

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-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 following mod_proxy_ajp directives in the Edit Directives module for this Virtual Server. Edit Directives is found in the Control Panel, Apache Webserver - click on the icon for the Virtual Server you wish to edit, and then on the Edit Directives module. You can also add these lines to the correct VirtualHost block in the httpd.conf file using the File Manager, or from the command line.

# 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 Cloud server 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

Stop and Disable Apache

To stop and disable Apache, you will need to stop the service, and then chkconfig the service off so that it does not start when the VM is rebooted.

[root@i-3-154-VM ~]# service httpd status
httpd (pid 1588) is running...
[root@i-3-154-VM ~]# service httpd stop
Stopping httpd: [ OK ]
[root@i-3-154-VM ~]# service httpd status
httpd is stopped
[root@i-3-154-VM ~]#


[root@i-3-154-VM ~]# chkconfig --list httpd
httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@i-3-154-VM ~]# chkconfig httpd off
[root@i-3-154-VM ~]# chkconfig --list httpd
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@i-3-154-VM ~]#

Now the Apache web server is stopped, and can only be restarted by manually using the service httpd start command.

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 eapps-example.com

In this example, the application is packaged in a WAR, EAR or JAR file. The application will be served at http://eapps-example.com/ or http://www.eapps-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.

GlassFish v3 New Virtual Server

  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 eapps-example.com and www.eapps-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.

  6. 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.

  7. 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.

  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 eapps-example.com, but there is no Default Web Module set.

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

  10. 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.

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

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.

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.

NOTE - The following must be done from the command line of the Virtual Machine 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 server 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 server 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 server is running.

Generally, the maximum heap size should be just under half the amount of memory available to your Cloud server. You can of course adjust this value higher or lower, but you may have to experiment to determine the true optimum heap size.

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

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.


GlassFish main site - http://glassfish.java.net/

GlassFish documentation - http://glassfish.java.net/docs/project.html

(53 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.

DMCA Notice  |  Report Abuses  |  Legal Notice  |  Privacy Statement  | © 2012 Strategic Systems Consulting, Inc.