Tech

20121219

Diagnosable Oracle JDBC 11g Driver

The Oracle's 11g JDBC driver comes with a Self-Diagnosable features in which might help on the diagnose connection issue with the Data Base. Base on java.util.logging framework and javax.management MBean framework, in which follow the Java standard for monitoring and management.

  • java.util.logging _ Can be configure from providing a simple issue track, such as running out resource, to something more specific and detail tracing on an internal execution of a system. 
  • javax.management _ Can consult and change system's behavior through MBeans, accumulate statistics and notify in states changes on error's behaviors. 

The OJDBC self-diagnose, is not implemented in all the drivers. Actually you might need to go back to Oracles's driver site and download the following drivers:

  • ojdbc5_g.jar 
  • ojdbc6_g.jar

 *That's is why they have named these drivers with an *_g.jar at the end.

1- To enable the tracing you need to add at the java startup argument the following flag:

-Doracle.jdbc.Trace=true

This flags enable the global logging, if you want to debug the entire application this' the way to go.

2- Now we need to add the following flag on the java startup in which gives a path to an configuration file properties:

-Djava.util.logging.config.file=/jdbc/home/JDBCLogging.properties

3- Create the file /jdbc/home/JDBCLogging.properties; and set as following:

.level=SEVERE
oracle.jdbc.level=INFO
oracle.jdbc.handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=INFO
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

This will throw the output into the console, there fore no log file should be created. If you need to actually to produce a physical log you need to set as following:

.level=SEVERE
oracle.jdbc.level=INFO
oracle.jdbc.handlers=java.util.logging.FileHandler
java.util.logging.FileHandler.level=INFO
java.util.logging.FileHandler.pattern=jdbc.log
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter


The amount of details are controlled by choosing bellow values, from less information to most detail information:

  • OFF
  • SEVERE
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST
  • ALL
The 11g's OJDBC also lets you choose which system or part of the driver in which can be debugged; Is a nice thing, because some times you do not need too much information but specific information, and how to do this is controlling the logging level using the following flags:

  • oracle.jdbc 
  • oracle.jdbc.driver
  • oracle.jdbc.pool
  • oracle.jdbc.rowset
  • oracle.jdbc.xa
  • oracle.sql
*Subject to change by release version.
These flags can be simply add to the  /jdbc/home/JDBCLogging.properties like:

.level=SEVERE
oracle.jdbc.level=INFO
oracle.jdbc.driver.level=ALL *
oracle.jdbc.handlers=java.util.logging.FileHandler
java.util.logging.FileHandler.level=INFO
java.util.logging.FileHandler.pattern=jdbc.log
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter


ref: 








20121214

java.lang.OutOfMemoryError: GC overhead limit exceeded

The OOM: "GC overhead limit exceeded", only means that Full GC is doing much work for nothing. Too much time is being spent on Garbage collection while the collection it self recover less than 2% of the heap.

Accordingly this OOM can only occurs in two different GC algorithm, such as:

  • Parallel Collection: Parallel's automatic tuning, provide a maximum pause time. 
  • Concurrent Collection: The concurrent collector pauses an application twice during a concurrent collection cycle.

Only collections in which application is stopped, and is due to concurrency mode failure or explicit collection request. This OOM is to prevent applications to be stopped for a long period of time while collecting on a small heap.


Possible Solutions:

  • Use another GC algorithm;
  • Check if your heap is too small to run Parallel or Concurrent GC. If this is the case tune your heap size accordingly;
  • Turn off this feature by using: -XX:-UseGCOverheadLimit. This flag replaced the  UseGCTimeLimit, in which is referenced on the CR 6287811; 
  • Try use the -XX:MaxGCPauseMillis=n, in which the GC will try its best to achieve this value. No promises made on this one. 

Bug:
      The CR 6287811, is about the log output error in which mislead many people in thinking there were an issue with the heap:

  • before: "java.lang.OutOfMemoryError: Java heap space";

  • now: "java.lang.OutOfMemoryError: GC overhead limit exceeded";


Doc:

-XX:+UseGCOverheadLimitUse a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)



ref:
  • http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
  • http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
  • http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6287811

20121213

Using Wildcard asterisk (*) SSL with WLS

Setting the certificates to use the wild card asterisk (*) can be troublesome on the WLS.

Example of wildcard use:

cn = *.example.com

Since WLS 10.3.6 and 12.1.+ has been hard-coded a new host name verifier on the WLS in which with some simple configuration you can use your wildcarded certificates:

A_ Start WLS with the following java properties:

./startWebLogic.sh -Dweblogic.security.SSL.HostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier

or

B_

1. Start the AdminConsole and goto selected Server::Configuration::SSL;

2. Click on the link Advanced;

3. Copy/paste the weblogic.security.utils.SSLWLSWildcardHostnameVerifier Class name on the Hostname Verifier field;

4. Save;

C_ Restart server and test your SSL connection.


*For previous version of WLS 10.3.x there's a patch in which, I recommend to open an SR with Oracle to retrieved.


Links:
Using the Wildcarded Host Name Verifier
Configure a custom host name verifier
Oracle WebLogic Server API Reference SSLWLSWildcardHostnameVerifier