Friday, March 2, 2012

Configuring JBoss clustering through JAVA_OPTS

Hi Friends,
             There are different way to configure Jboss Clustering. Here you can see one on them...

Configuring JBoss clustering through JAVA_OPTS:

Issue


  • I need to configure my cluster through JAVA_OPTS.  What settings can I use for this?

Environment

  • JBoss Enterprise Application Platform (EAP)
    • 5.1.0

Resolution


  • The following all are the JAVA_OPTS needed to set up clustering:
    • -Djboss.messaging.ServerPeerID=
    • -Djboss.bind.address=
    • -Djboss.partition.name=
    • -Djgroups.udp.mcast_addr=
    • -Djboss.partition.udpGroup=
Regards,
Kuldeep Sharma

Jboss Monitoring Tips

Hi Friends,
              Below is the some information about memory and threads monitoring in Jboss. For this you can use jmx-console of Jboss. Just open your jmx-console (e.g http://localhost:8080/jmx-console). Then on left panel you will find jboss.system. After this just click on jboss.system:type=ServerInfo on right panel.

Memory and Thread Monitoring:

The jboss.system:type=ServerInfo MBean provides several attributes that can be used to monitor the thread and memory usage in a JBoss instance. These attributes can be monitored in many ways: through the JMX Console, from a third-party JMX management tool, from shell scripts using the twiddle command, etc... The most interesting attributes are shown below
.
FreeMemory
This is the current free memory available in the JVM.
ActiveThreadCount
This is the number of active threads in the JVM.
ActiveThreadGroupCount
This is the number of active thread groups in the JVM.
These are useful metrics for monitoring and alerting, but developers and administrators need a little more insight than this. The Java 5 JVMs from Sun provide more detailed information about the current state of the JVM. Some of these details are exposed by JBoss through operations on the SystemInfo MBean.
listMemoryPools
This operations shows the size and current usage of all JVM memory pools. This operation is only available when using Java 5.
listThreadDump
This operations shows all threads currently running in the JVM. When using Java 5, JBoss will display a complete stack trace for each thread, showing you exactly what code each thread is executing.
listThreadCpuUtilization
This operations shows all threads currently running in the JVM along with the total CPU time each thread has used. The operation is only available in Java 5.


!Hope this will help you
Regards,
Kuldeep Sharma


About Ports Used in Jboss


Hi All,
This is small information about different ports used by jboss. Usually we know we get familiar with only few commonly used ports(e.g. 8080, 8009 etc). But actually there are some more which are internally configured for different services.


Supposing we have bound JBoss AS to the IP Address 10.2.20.156, here's the list of ports engaged by the application server:
TCP    10.2.20.156:1090       <--- RMI/JRMP socket for connecting to the JMX MBeanServer
TCP    10.2.20.156:1091       <--- RMI server socket

TCP    10.2.20.156:1099       <--- JNDI Service
TCP    10.2.20.156:1098       <--- RMI Port for JNDI Service
TCP    10.2.20.156:4446       <--- JBoss Remoting Connector
TCP    10.2.20.156:4712       <--- JBossTS Service
TCP    10.2.20.156:4713       <--- JBossTS Service
TCP    10.2.20.156:5445       <--- HornetQ JMS Service
TCP    10.2.20.156:5455       <--- HornetQ Netty port
TCP    10.2.20.156:5500       <--- JBoss Remoting
TCP    10.2.20.156:5501       <--- JBoss Remoting ssl
TCP    10.2.20.156:8009       <--- Web server AjpConnector
TCP    10.2.20.156:8080       <--- Web server HTTP Connector
TCP    10.2.20.156:8083       <--- Web services



Clustered servers will additionally open the following ports:

TCP    10.2.20.156:1100       <--- HA JNDI Service
TCP    10.2.20.156:1101       <--- HA JNDI Service
TCP    10.2.20.156:3528       <--- Corba IIOP Service



The Service Binding Manager
 The Service Binding Manager co-ordinates which ports the JBoss Application Server instance listens on when it starts up and the Administration Console provides a mechanism for configuring this service to change which ports get used.
 The Service Binding Manager can be used to change the default port sets, without changing the single service ports.
 Out of the box, the JBoss Application Server ships with four port sets defined as:

* ports-default: The standard ports, for instance JBoss HTTP is on 8080.
* ports-01: The standard ports incremented by 100. For example, HTTP is on 8180
* ports-02: The standard ports incremented by 200. For example, HTTP is on 8280
* ports-03: The standard ports incremented by 300. For example, HTTP is on 8380

 In order to change the port set you can edit the file bindings-jboss-beans.xml and set for example the ports-01
<parameter>${jboss.service.binding.set:ports-01}</parameter>
You can as well change the Service Binding ports from the start-up script of the application server. For example:
run -Djboss.service.binding.set=ports-01


Note : This is pretty useful if you don't have to maintain a separate copy of the all folder if you want to, say, start up multiple instances of JBoss running as a cluster.






Regards,
Kuldeep Sharma

JDBC connection pool running out of connections in JBoss EAP


Issue

  • Application Server runs out of available connections in the connection pool
  • Message appears in the server.log file
·         No ManagedConnections available within configured blocking timeout
  • Server hangs

Environment

  • JBoss Enterprise Application Platform (EAP)
    • 4.x
    • 5.x

Resolution

  • Increase your connection pool size.  Add the following
<max-pool-size>whatever</max-pool-size> 
to the *-ds.xml file to increase the number of connections available. The default is 20.

  • The following attribute of the ManagedConnectionPool MBean in the jmx-concole, for the datasource in question, can help understand how many connections are really needed.
MaxConnectionsInUse

  • Tell your threads to wait longer for a connection to open up.  Add the following
<blocking-timeout-millis>whatever</blocking-timeout-millis> 
to the *-ds.xml file to increase the length of time to wait. The default is 30000 milli-seconds.

  • Fix the offending code so that connections are closed. Especially if you see - 
Closing a connection for you. Please close them yourself

Diagnostic Steps

  • Ensure the CachedConnectionValve is installed and CachedConnectionManager debugging is enabled in order to show where the connection leak is coming from. The CachedConnectionValve is installed by default in EAP.  CachedConnectionManager debugging depends on the server profile (enabled  in default and all, disabled in production).
  • Configuration details is as follows:

    • EAP 4.x
      • CachedConnectionValve: JBOSS_HOME/server/$PROFILE/deploy/deploy/jboss-web.deployer/server.xml
      • CachedConnectionManager is configured in  JBOSS_HOME/server/$PROFILE/deploy/jbossjca-service.xml .  Debugging is enabled as follows:
  <mbean code="org.jboss.resource.connectionmanager.CachedConnectionManager" 
         name="jboss.jca:service=CachedConnectionManager">
    <depends optional-attribute-name="TransactionManagerServiceName">jboss:service=TransactionManager</depends>
 
    <!-- Enable connection close debug monitoring -->
    <attribute name="Debug">true</attribute>

    • EAP 5.x
      • CachedConnectionValve:  JBOSS_HOME/server/$PROFILE/deploy/deploy/jbossweb.sar/server.xml
      • CachedConnectionManager is configured in JBOSS_HOME/server/$PROFILE/deploy/jca-jboss-beans.xml. Debugging is enabled as follows:
  <bean name="CachedConnectionManager" class="org.jboss.resource.connectionmanager.CachedConnectionManager">
 
      <!-- Whether to track unclosed connections and close them -->
     <property name="debug">true</property>
 

  • Search server.log for the following:
INFO [CachedConnectionManager] Closing a connection for you. Please close them yourself
  • Review associated stack trace to find the code that's not releasing connections.
  • Identify the code which is leaking the connection.  By using the CachedConnectionManager from the JMX Console:
    1. Log into the JMX Console (e.g. http://jboss-host:8080/jmx-console).
    2. Scroll down to the "jboss.jca" section.
    3. Click the "service=CachedConnectionManager" link.
    4. Scroll down and invoke the "listInUseConnections" operation.
    5. A stack trace for each in-use connection will be printed. (Only if CachedConnectionManager is in debug mode)
  • Take subsequent readings from listInUseConnections() say after the interval of 10 seconds and figure out from the trace which application code is holding the connections for longer time.  This will help in detecting the application code which probably would be leaking the connections.
  • Look at the database connections from the database side to see what SQL is running on the connections.  Make sure there is not any long running SQL or recursion bugs in the SQL that could be causing the connections to never be released.


Regards
Kuldeep Sharma