anandraj Archive

Changing default session timeout Jboss 7

JBoss Enterprise Application Platform 6 has a default session bean timeout of 30 minutes, which is configured in standalone/configuration/standalone.xml

The default HTTP session timeout can’t be modified in EAP 6.

To override default value for your own application, follow the below approaches:

  1. Add an entry in the application web.xml file:


2. Programmatically override the session timeout for a particular session.

HttpSession session = request.getSession();

Note:  In older versions of Jboss Application Server ex. Version 5, it provided a provision of overriding the global session time out setting from the Jboss web.xml file under the location $JBOSS_HOME \server\default\deploy\jboss-web.deployer



Further reading:



Wonders Team

JConsole for monitoring Weblogic Application Server 12c

Performance and high availability of production systems are critical for any business. Hence there is a plethora of monitoring tools available in the market that helps you to monitor your production systems, generate alerts, and trigger emails in down time situations. Few commercially available monitoring tools in the market are wily introscope, Appdynamics etc.

For further details on wily introscope.

For further details on Appdynamics.

Apart from commercially available monitoring tools, there are few freely available monitoring tools like jconsole, jhat, jstack and weblogic’s very own JRMC, WLDF (For performance monitoring).

This post is a sample illustration of how we can configure Jconsole with WebLogic Application Server for monitoring.

What is JConsole?

The JConsole graphical user interface is a monitoring tool that complies to the Java Management Extensions (JMX) specification. JConsole uses the extensive instrumentation of the Java Virtual Machine (Java VM) to provide information about the performance and resource consumption of applications running on the Java platform.



How do I configure Jconsole with weblogic application server?

Local server monitoring:

  1. Set the classpath by running setDomainEmv.cmd from <WLS_DOMAIN_HOME>\bin
  2. Start Jconsole.exe  ( Alternatively you can execute it from from the default java location :  C:\Program Files\Java\jdk1.6.0_45\bin\)
  3. Select the Weblogic Server instance from the local process list.


Jconsole Weblogic Application Server 1

Jconsole Weblogic Application Server 1

4: Monitor the server nitty-gritty details:

Jconsole Weblogic Application server 2

Jconsole Weblogic Application server 2



Remote Server Monitoring using JConsole:

  1. Update the setDomainEnv.cmd  with the below parameters in the JAVA_OPTIONS and restart the Weblogic Server

For non- authenticated user and non – ssl mechanism:


For authenticated SSL mechanism:

2. Set the classpath and start JConsole

jconsole -Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar:</code> <code>$WLS_HOME/server/lib/wlfulclient.jar -debug

3. Connect using hostname and port


You will have access to all the details of the remote JVM

For accessing only the MBeans:

If you want to connect only to the JMX MBeans follow the below steps:

1. Login into the Weblogic Admin Console and navigate to the server that needs to be monitored, set the username / password for the IIOP protocols.



Note: Restart the designated server

2.       Set the classpath and start JConsole.

jconsole -Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar: $WLS_HOME/server/lib/wlfulclient.jar -debug

3.       Connect to the server Mbeans using the service URL as below:




Note: You would not see other JVM details but only the domain runtime MBeans

Further reading:

Common Exceptions:

1. Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound:]

Possible solutions:

Make sure the JMX Service url is correct and the JNDI value is properly mentioned.

2. org.omg.CORBA.NO_PERMISSION:   vmcid: 0x0  minor code: 0  completed: No

Possible solutions:

The server failed to authenticate the IIOP client or the server port is not defined properly.

Change the default IIOP username / password for the weblogic server.



Wonders Team.

Auto Deployment and Hot Deployment

Auto Deployment:  

Features provided by the Application Servers in which applications can be automatically deployed / undeployed on to the server. The App Server provides a mechanism where they scan certain folders for the applications for ex. autoDeploy folder in weblogic, deploy folder in tomcat / Jboss etc.

Hot deployment:

The process of adding new components (such as WAR files, EJB Jar files, enterprise Java beans, servlets, and JSP files) to a running server without having to stop the application server process and start it again.  

Hot deployment is mainly used to update the individual modules or jsps/servlets/classes in a module without redeploying the complete app.

Auto Deployments of Web Applications in WebLogic Server:

This is the simplest form of deployment. When enabled the Admin Server periodically scans the autoDeploy folder and deploy all the applications present in there.

Note: This feature is disabled in the production mode.

Production mode of the application server can be changed using the handle –Dweblogic.ProductionModeEnabled=true in the server startup file.

Need of Auto Deployment:

This is a very quick way of deploying the application which can be using during development and unit testing phase to reduce the deployment time.

How to auto Deploy:

1. Start the WebLogic Server domain in development mode.

2. Place the application’s exploded directory structure or archive file in this autodeploy directory.

It is present under $DOMAIN_HOME folder structure.

Hot Deployment (Redeployment Strategies) in Weblogic server:

This can be achieved by using different Redeployment Strategies.

Production Redeployment:  

Production redeployment strategy involves deploying a new version of an updated application alongside an older version of the same application. WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older version of the application until they complete their work, at which point WebLogic Server automatically retires the older application.

In-Place Redeployment:

In-place redeployment immediately replaces a running application’s deployment files with updated deployment files. In contrast to production redeployment, in-place redeployment of an application or stand-alone J2EE module does not guarantee uninterrupted service to the application’s clients. This is because WebLogic Server immediately removes the running classloader for the application and replaces it with a new classloader that loads the updated application class files.

Partial Redeployment of Static Files:

WebLogic Server enables you to redeploy selected files in a running application, rather than the entire application at once. This feature is generally used to update static files in a running Web application, such as graphics, static HTML pages, and JSPs. Partial redeployment is available only for applications that are deployed using an exploded archive directory.

Partial Redeployment of J2EE Modules :

Partial redeployment also enables you to redeploy a single module or subset of modules in a deployed Enterprise Application. Again, partial deployment is supported only for applications that are deployed using an exploded archive directory.

Further reading.

Happy Reading.

Wonders Team 🙂