Tuesday Feb 10, 2009

JDBC Pool Manager - Max Pool Size Tuning

Max pool size is the maximum number of connections to the database at any point of time. This value can be configured as a jdbc connection pool attribute "max–pool–size". The default value of this attribute is 32. 

Some databases have license restrictions on how many connections it can allow. This attribute is configured based on such parameters.  This parameter can also be configured from the Performance Advisor page in administration console of GlassFish. Some important points to note here :

  • If one or more jdbc connection pools are selected in the JDBC Pool Manager, there is an option to specify a "Max Connections" value for each pool according to the requirement. 

  • The Default Max Connections set to a certain value overrides the settings of the max–pool–size of the selected jdbc connection pools.

On a clustered environment, when new instances are added to the cluster, the max–pool–size on each instance may need a reconfiguration. This should also be based on the instance weights. A particular instance may have a higher instance weight, say, to provide faster service to privileged customers.

  • Create a node–agent called na1

  • Create a cluster "mycluster" with 2 instances "instance1" (weight 40) and "instance2" (weight 60)

  • Start the cluster "mycluster"

  • Create a new JDBC Connection pool "mypool" with default settings

  • Create a new JDBC resource referring the above connection pool for target "mycluster" : "jdbc/myresource"

  • Create an application that refers this jdbc resource on "mycluster" target

Clustered environment

  • In the performance advisor link of admin console, specify the default max connections for "mypool" as 100. Enable this rule on "mycluster" by choosing "mycluster" for target. Jdbc Rule Manager

Setting target as mycluster

After these steps, the "mycluster" should be restarted to see the max pool size reconfiguration in each of the instances "instance1" and "instance2".

You would see, for "instance1", the max pool size is recalculated to 40

instance1 log from admin console

and "instance2" to 60 based on their instance weights.

instance2 log from admin console

  • Add another new instance "instance3" to "mycluster" with weight of 100.

  • Restart "mycluster".

Once the cluster is restarted with the new instances addition, the max pool size of instance1 becomes 20, instance2 becomes 30 and instance3 becomes 50. This is based on the instance weights and the default max connections value we specified for the jdbc connection pool. instance3 gets more number of max connections to the database since its instance weight is higher.

instance1 log from admin console after instance addition
instance2 log from admin console after instance addition
instance3 log from admin console after instance addition

This is a very useful rule to configure the maximum pool size of jdbc connection pools on cluster startup. Manual intervention is prevented and this easy–to–use feature can be configured to avoid errors in complex cluster scenarios.

JDBC Pool Manager - Steady Pool Size Tuning

Sun has recently announced the "GlassFish Enterprise Manager". I would talk about a particular feature : "Performance Advisor". One of the management rules of Performance Advisor is the JDBC Pool Manager. Jdbc pool manager tunes the steady pool size and maximum pool sizes of jdbc connection pools based on the load. This blog would briefly talk about steady pool size tuning.


Consider a cricket website. On a non–match day, there will be a minimum number of requests to this website. On a match–day, even if it is a working day, people tend to use such websites to check the runs and number of wickets. The number of requests will pour in as a result and for maximum resource utilization, the steady pool size needs to go up. If done manually, the administrator will have to configure this steady pool size.

 After  a while, number of requests are bound to come down. As a result, the steady pool size would have to be brought down. This constant recomputing of steady pool size based on the load is automated by the JDBC Pool Manager.

How is it Configured?

Assume there is a jdbc connection pool : cricket–info–pool. jdbc/cric is the resource that references this pool. The cricket–info–pool is set to a default steady pool size of 8. An application that uses the jdbc resource to get information from a database is set up. Client access this application to retrieve information. JDBC Pool Manager rule can set up from admin GUI.

  • The Default Max Connections is the maximum number of connections that can be provided from the pool at any point of time.

  • The management rule tunes the steady pool size in Sampling Frequency number of seconds.

  • The sample size denoted by Number of Samples is used to calculate the moving average value for number of connections.

Marking cricket-info-pool under PoolNames will configure the rule for this connection pool.  Click on Save after entering all the details.The domain needs to be restarted now, as the rule is configured for the target "server".

On domain restart, you can observe from the server.log that the steady pool size is recalculated to a certain value. After a while, assuming there are 500 client requests for a period of 10 minutes.

The steady pool size is recalculated every 60 seconds (default sampling frequency) to a new value suitable for the current number of requests.

Thursday Nov 06, 2008

JDBC support in V3 Prelude

The latest application server of Sun – GlassFish V3 Prelude includes JDBC support. The JDBC Connection pooling infrastructure in V3 prelude is same as that of GlassFish 9.1 application server.

Some of the cool features that could be useful to you are :

  • Connection Leak Tracing

    •  enable the connection-leak-timeout to a certain value along with connection-leak-reclaim to true to avoid the potential connection leaks in your application

  • Validation calls optimization

    • Set the validate atmost once period to a value within which the validation will be carried out atmost once.

  • Associate with thread

    • To reuse connections in a multi threaded application to avoid the overhead of getting a connection from the pool.

and many more...

Things that have changed:

Setting the pool properties/attributes using asadmin set command would be like:

asadmin set --value=10 server.resources.jdbc-connection-pool.DerbyPool.steady-pool-size

asadmin set --value=newUser server.resources.jdbc-connection-pool.DerbyPool.property.User

Note that the first asadmin set does not need a server restart whereas the second one mandates restart.

There are many more attractive things coming up in the next release of V3 for JDBC. One of them is advanced pool monitoring. The monitoring framework has undergone a major change in v3 prelude.

Try the latest V3 prelude and its connection pooling features. Any issues? Mail users-AT-glassfish.dev.java-DOT-net .

Tuesday Feb 27, 2007

GlassFish Upgrade Story

Why do you want to upgrade?

Well!!! Lot of reasons!!! Take the example of a browser, mozilla. In the update center, you get to know some cool feature X has been released in the next version. You want to get the new version, but do not want to lose your current data and configuration, like bookmarks etc. Mozilla upgrades in the way we want to keep our customized data. When browser is restarted after an update, you see that cool feature X along with all your previous configuration.

Would this not be cool if something like this happens in the Application Server too. There are new versions of GlassFish coming up and you might want to do the same thing - upgrade from a previous version to the latest version. The good news is, you could do that!!! And i'm going to explain just that, with some links for you.

Some of the following terms speak a lot about the Upgrade tool of GlassFish.

Side-by-Side Upgrade:

Installing application server in different locations and performing an upgrade. For ex: SJSAS8 is installed in /opt/SJSAS8 and GlassFish is installed in /opt/GlassFish. When upgrade is performed from /opt/SJSAS8 to /opt/GlassFish, it is called a side-by-side upgrade.

In-place Upgrade:

Installing application servers in the same location. For ex: SJSAS8 is installed in /opt/Appserver and you would like to install GlassFish also in the same location, to save some space, the inplace upgrade happens.

Binaries Vs Configuration:

When you install GlassFish, you would see under the install root, "bin", "lib", "domains" etc. The "domains" directory would contain all the configuration information like "deployed applications" and customized settings pertaining to each of the domains under it. The other directories are the binaries of the application server you have installed, with which new features become usable. These include the "config", "bin", "lib" etc.


When an upgrade is performed, the binaries and configuration, both have to be transferred. This could be done In-place or Side-by-side (explained above). In both the cases, the transfer of binaries is done by the GlassFish installer and the configuration transfer is done by the AS Upgrade Tool. This is clearly demarcated, in the sense that, a binary upgrade could be done with/without the configuration upgrade. The configuration is not affected unless the AS Upgrade Tool is invoked.

AS Upgrade Tool Functionality:

The Upgrade tool works in these simple steps. It could be invoked in the following ways :

  • Running asupgrade from the install_root/bin directory. This invokes the GUI mode of the tool.

  • Executing asupgrade -c from the install_root/bin directory. This invokes the CLI (Command Line Interface) mode of the tool.

  • asupgrade -c has some more options as well, for mentioning the source and target locations. For details, on this, refer the Upgrade tool manual.

When upgrade tool is invoked in one of the above modes, it prompts for the source and target locations. Here source location refers to the directory of the domain that needs to be upgraded. Target refers to the GlassFish application server domains root to which the configuration is to be upgraded. In an In-place upgrade, the domains root directory will be the same.

Apart from these, the admin credentials are also prompted for. When all these details are provided, upgrade tool creates the necessary domains, transfers the configuration, transfers the applications deployed, transfer the realms and logs all these into an upgrade.log. By all these what i mean is that, the domain.xml under domain config directory is modified to incorporate all the config changes from the source.


These are some of the links that could be useful to you.
1. Prasad's blog : http://blogs.sun.com/prsad/entry/upgrading_to_glassfish
2. AS Upgrade One Pager : http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/upgrade-one-pager.html

Thursday Jan 19, 2006

GlassFish : Self Management Rules

Self Management is an initiative taken in GlassFish to reduce the complexity of the management tasks. Mundane management tasks are automated by means of self-configuring. System Administrators who are responsible for monitoring the application server for unpredictable conditions no longer have to detect them manually. This is an easy-to-use feature that comes in handy at the unpredictable run-time conditions. This feature enables to recover from failures by detecting and preventing them, thus improving availability (self-healing). Even security threats are detected and self-protective actions are taken in response. The framework has been developed using standard technologies.

Self Management comprises of a set of management rules. You could create different rules based on the various event types. As mentioned at glassfish.dev.java.net, the different type of events are as follows.
  • Lifecycle events
  • Monitor events
  • Log events
  • Trace events
  • Timer events
  • Notification events
This blog is more about how to create management rules easily. I will show examples for some of the different type of rules. The action we take in response to the occurrence of an event, could be anything from sending an email notification to displaying an alert or killing some processes depending on what is appropriate for the particular event.

Let us take an example of displaying a pop-up window as an alert. Action mBeans implement the NotificationListener interface. The handleNotification() method for our action will look like the following.

    public synchronized void handleNotification(Notification notification,Object handback) {
        try {
            JFrame. setDefaultLookAndFeelDecorated(true);
            JFrame myFrame = new JFrame("MyAction");
            myFrame. setSize(250, 180);
            myFrame. setLocation(300,200);
            myFrame. getContentPane().add( new Label("Action has been invoked",Label.CENTER), BorderLayout.CENTER);
            myFrame. setVisible(true);
            myFrame. show();
        } catch (Exception ex) { // Log the exception }

Let us name this class as CustomAction which is in the com.sun.myrule.action package. It has a corresponding CustomActionMBean. Follow these steps to deploy the action on the application server.

1. Compile the files and make a jar out of these two files.

2. After starting the application server, open the admin console by typing http://localhost:4848 on a browser.

Figure1: Admin Console

3. On the left pane, click on "Custom MBeans". On the right pane, all the deployed mbeans are listed. To deploy our action mbean, click on Deploy. Select the jar file that you just created against the "File to upload" column and click Next.

Figure2: Custom MBeans

Figure3: Creating Custom MBeans

4. Enter a name for the mbean. This will later be used while creating the rule. Enter name as "CustomAction".

5. Enter the class name along with the package name. In this case, it is com.sun.myrule.action.CustomAction.

Figure4: Creating Custom MBeans: Step 2

6. Click Finish.

The action mbean is successfully deployed on the application server.

We will use the same action mbean for all the rules. This action mbean will be called each time an event is triggered. For more information on actions, refer to actions section in glassfish.dev.java.net

Now let us proceed and create rules.

Simple rules for creating a rule:

1. Identify the event type you need. For example : lifecycle
2. Identify the mandatory and optional properties for that event type. For example : lifecycle event requires a property called "name".
3. Identify the action mbean you would like to use for your rule.
4. You could use the Application server Command line interface (CLI) or the Graphical user interface (GUI) to create rules.
5. Make sure the server is started before proceeding with rule creation.

Example 1 : Assuming the administrator wants to be notified everytime the application server shuts down or is terminated because of a failure. Continuous monitoring is necessary for this kind of a situation. Therefore, a rule could be created mentioning a notification to be sent to the administrator when this event is triggered. Management rule bundles together the event and the action.

Let us examine how this rule could be created.

After starting the application server with the command "asadmin start-domain", use either CLI or GUI to create the rule.

CLI mode :

/bin/asadmin create-management-rule
--host localhost --port 4848 --user admin
--action CustomAction
--eventtype lifecycle
--eventloglevel WARNING --eventproperties name=shutdown

GUI mode :

  • Start admin console by typing http://hostname:port on a browser, after starting the application server.
  • Go to the Management Rules tab under the Configurations tab in the left pane. This displays the list of rules deployed on the server on the right pane.

  • Figure5 : Management Rules

  • Click on New
  • Type the name of the rule as "my_lifecycle_rule".
  • Check the Status checkbox to enable the rule.
  • Enter description
  • Choose event type as lifecycle.
  • Click on Next if you are done with this page.

  • Figure6 : New Management Rule

  • In the next page, select "shutdown" against Event and enter a description if desired.
  • Select "CustomAction" listed in the action list box and click Finish.

Figure7 : New Management Rule : Step 2

The rule is successfully created and is deployed on the application server. The action will be triggered everytime the application server shuts down. Similarly, rule could be configured to take some action on ready and termination.

Example 2 : The administrator wants to be beeped once in a while regarding some status. A rule could be created to do this as follows.

CLI mode :

/bin/asadmin create-management-rule
--host localhost --port 4848 --user admin
--action CustomAction
--eventtype timer
--eventloglevel INFO
--eventproperties pattern=MM\\\\/dd\\\\/yyyy\\\\/HH\\\\:mm\\\\:ss:

Note here that "/" and ":" are escape sequences. Period, mentioned in milliseconds, is the period after which the notification is to be sent after the date mentioned in datestring.

GUI mode :
  • Start admin console by typing http://hostname:port on a browser, after starting the application server.
  • Go to the Management Rules tab under the Configurations tab in the left pane. This displays the list of rules deployed on the server on the right pane.
  • Type the name of the rule as "my_timer_rule".
  • Check the Status checkbox to enable the rule.
  • Enter description
  • Choose event type as timer.
  • Click on Next if you are done with this page.
  • Enter the values for datestring, pattern and other fields.
  • Select "CustomAction" listed in the action list box and click Finish.
Another example of a rule to monitor the runtime memory of the JVM can be found here .




« July 2016