Friday, March 23, 2012

JDBC Driver Error with MSSQL DB

Encountered this JDBC driver error when my multiple threaded client was inserting records to the MSSQL DB. 


java.sql.SQLException: Transaction (Process ID 59) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:368)


The quick way of solving it is to modify SQL server settings. From SMSS,  advanced settings can be configured to help prevent unintentional issues such as a query that causes locking or blocking. 


To access these settings in SSMS, choose Tools -> Options…  ->  Query Execution -> SQL Server -> Advanced dialog box.


1. Change SET TRANSACTION ISOLATION LEVEL to READ UNCOMMITTED :
This will minimize the impact of your ad-hoc queries by allowing dirty reads. While this can be beneficial for many production environments, make sure to understand the implications of this setting before implementing.


2. Change SET DEADLOCK_PRIORITY to Low :
This will tell SQL Server to select your session as the victim in the event of a deadlock.


3. Change SET LOCK TIMEOUT to a smaller, defined value, such as 30000 milliseconds (30 seconds):
By default, SQL Server will wait forever for a lock to be released. By specifying a value, SQL Server will abort after the specified timeout period when a lock is encountered. 


Though, this solution from server side solves the above issue, it is always not recommended as it could applies dirty read setting to all the DB instances and other transactionally important application may behave odd due to this.

CXF Embedded Application in JBoss-6.x AS

The CXF libraries stuffed in web applications lib folder to enable webservices capability usually works fine with servers like Tomcat (at least till version 6) which has by default no CXF related libraries at server path. But same web application fails even to get deployed in JBoss6.x conflicting with server provided CXF libraries.

When I faced the same issue, it took solid 8-10 hours to find out working solution. Hope my findings helps someone in same despair.

This issue made me take serious look at the class loading behavior of JBoss and I was certain that JBoss would have feature to disable or yield parent (server) classes loading. I have seen the same feature in Websphere application server. With full confidence, I have tried JBoss recommended ways of adding jboss-app.xml, jboss-classloading.xml and jboss-scanning.xml to web application path to make it look for classes from its own lib folder first.

I have tried giving the jboss-app.xml file different names like jboss-app.xml, jboss-web.xml and jboss-.xml etc. to see it work. I was thinking that I was missing correct syntax here and tried many options in vain.

Similarly tried many options with jboss-classloading.xml and I was sure about the following element and unfortunately, this also did not solve the problem.

 I knew surely that the above approach is cleaner and recommended way to go for which was not yielding any result.

As a last resort, I have physically removed all the CXF libraries from server end itself. I have found some cxf related files at common/lib and removed all cxf*.jar from there. Also, from server/default/Deployers/jbossws.deployer directory removed all jars. After these changes, when server was restarted some errors in boot.log appears related to the missing cxf jars but the web application got deployed successfully and functionality was intact.

Probably, it is good to use Jboss 7 as it claims to provide flexibility in choosing webservices kit (either cxf or native) and choosing native kit could resolve cxf classloading issues. Never tried though!



Please take note that this could stop other applications (if any) which depends on JBoss provided CXF libraries! 

Managing JVMs in RHEL

Java fraternity new to Linux environments usually face the trouble of managing JVM instance in terms of upgrading or migrating them. Some time back, when I wanted to remove the old JVM instance, I too faced this issue and hope this solution I found, would help others save some time.

Below step by step approach would help the beginners:

1. Download rpm.bin file
2. run : ./*.bin
3. Follow below steps to remove the old java and add new java into environment

Re configuring the default Java configuration for Red Hat / Fedora

This is done as root or equivalent.

First remove /var/lib/alternatives/java file by typing;

rm /var/lib/alternatives/java

When asked press the 'y' key,

Now to create the new (corrected) alternatives file for java type
the following commands as root (modify for jdk as needed);

/usr/sbin/alternatives --install /usr/bin/java java /usr/lib/jvm/jre-1.4.2-gcj/bin/java 1

/usr/sbin/alternatives --install /usr/bin/java java /usr/java/jre1.6.0/bin/java 2

/usr/sbin/alternatives --config java

You should now see for example:

There are 2 programs which provide 'java'.

Selection Command
-----------------------------------------------
1 /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*+ 2 /usr/java/jre1.6.0/bin/java

Enter to keep the current selection[+], or type selection number:

Type:

In the example above java is already configured correctly [*+ 2] to use Sun's Java, no changes are needed, just press the Enter key here. If you have been following the instructions then you should have the same results (version numbers may be sightly different).

Now type; /usr/sbin/alternatives --display java

You should see for example;

java - status is manual.
link currently points to /usr/java/j2re1.5.0_09/bin/java
/usr/lib/jvm/jre-1.4.2-gcj/bin/java - priority 1
/usr/java/jre1.6.0/bin/java - priority 2
Current `best' version is /usr/java/jre1.6.0/bin/java.

Next you might want to create (or edit) /etc/profile.d/java.sh
file, example below;

export JAVA_HOME="/usr/java/jre1.6.0/bin/bin"
export JAVA_PATH="$JAVA_HOME"
export PATH="$PATH:$JAVA_HOME"

When done creating or editing the file type;

source /etc/profile.d/java.sh

Now any user root or other wise should be able to use the command;

which java

and the results should read something like;

/usr/bin/java

Also any user root or other wize should be able to use the command;

java -version

and the results should read something like;

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

Java Program as a Service in Windows

When first time heard about the requirement of running java programs as a Windows service, my mind ran right towards java native (JNI) programming. Took really some time to figure out that there is a simple way to achieve this. That simple way is to use just one ready made jar file for the same occasion.    
Thought of sharing this which I''m sure many test and development boxes setup requires this for some quick testing references.

There is a free utility tool available for this and can be downloaded from Java Service Launcher (JSLWIN).

The description says that it is a lightweight tool to run Java applications as Windows (NT, Win2000, Win2003) services. JSL is released as a ready to use executable. Setup is straight forward including just one executable and one configuration file.

Thought, there are many ways to achieve it, the way I set up was something like below:

1. Download JSL utility and place it in some directory. IN my case it is E:\JSL

2. Created ServiceLauncher class which in turn calls my entry class. Build jar file for the same.

3. JSL.jar need to be placed in lib folder along with the module that need to be made run as a service and dependent jars. ServiceLauncher.jar to be placed in JSL.

4. Change the Java path, JSL path, library path and very importantly working directory information in jsl.ini file

5. Place all the module related files(XML and classes here) in E:\JSL

6. From command prompt, run jsl -install to install the module as a service

7. Start the service from windows service console

8. To remove the sevice from console, stop the service and then run jsl -remove

9. To test before install, run jsl -debug or jsl -run




Thursday, March 22, 2012

OpenCMIS Class Loading Behavior

Ever tried OpenCMIS client in any web applications and observed performance issues with that. I did find that recently using OpenCMIS 0.4 version with my web application deployed in Tomcat 6. The issue I faced was classes loaded were kept on growing and looks like it was never garbage collected even after stopping that particular application. The free tool VisualVM was used to analyse this along with jmap and jhat utils from jdk 1.6 to see the strong references which never gets unreachable. With these tools it was clearly evident that even after redploying the particular web application, references of the loaded classes were not removed.

The in-depth analysis to the problem helped me to learn some nuances of class loading mechanism. Thanks to the problem and thought of sharing the same here.

Some reasons that could cause this problem:

1. Frequent offenders are scripting languages, dynamic proxies (including the ones generated by application servers)

2. Custom class loaders that don't carefully free up older classes after loading new ones

3. Also, Tomcat container holds the reference for the opencmis classes(specifically JAXB static references) and cleanup never happens. This cold be a limitation running CMIS code from JSP/Servlets.

4. Heavy use of Proxy classes, which are created during run time

5. Just like Hibernate, OpenCMIS creates and loads new classes on the fly at run time, and thus drawing heavily on the (possibly non-heap allocated) method area of the JVMs memory space. The behavior is expected in case of on the fly created classes. When application is not generating classes on the fly, the number of loaded classes and amount of permgen should be more or less static.


Finally, the solution which worked out in my case:

1. Added -XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC to JAVA_OPTS in catalina.bat
2. Replaced jaxb-impl2.2.1 wih version 2.2.3 jars jaxb-impl.jar and jaxb-api.jar

Other problem I have observed here is whenever the testui web application stopped from tomcat console, web application class loader does not unload CMIS JAXB classes because of which we see memory leak likely to happen message. Here we have not much control or it is not recommended to tweak the class loader functionality. Instead just stop and restart Tomcat.

Thursday, March 15, 2012

Failed Synaptics Touch pad in HP EliteBook 8460P

Thought of blogging this experience strikes me after helping three geeks facing same issue of Touchpad failing in their brand new HP models.

This is the classic example of digital annoyance I faced in recent times with the touchpad of new HP Elitebook 8460P model failed to respond with a minute LED glowing on it.

Quickly checked the device driver and there were no visible errors as such. Restarted system couple of times which is a last resort of most of the users for all kind of PC problems. The moment windows OS got loaded, the light glows back on the touchpad mocking my technical aptitude. The next step I took was to upgrade the driver to 15.3.25 by uninstalling the older version. This too made no difference and the light was still glowing ridiculing my finger movement with no response over the screen.

Borrowed neighbor's mouse to check if that works and at least my expectations were meeting with that. Searched all over the net with different search engines and in lot many forums but none of the solutions worked for me. Four hours passed and I was still struck with no answer. Frustrated, I wanted to try one last time before I call upon IT desk and then I found the treasure. It was there on quick launch tool bar glittering!

Whosoever struck in similar problem, just follow below steps to get nirvana from Touchpad problem.

1. Uninstall the Synaptics PS/2 Port Touchpad driver from Device Manager.
2. Install the latest version in my case it was 15.3.25.
3. Restart the system
4. Identify the Synaptics Pointing Device Icon from Quick Launch toolbar
5. Click on icon to open the Mouse properties dialogue box
6. Click on Device Settings tab
7. Enable all the devices listed out there and apply settings
8. There you see! Lights off! Freaking light..

Remember a zen's saying on "what after nirvana?" Same thing here. I still use Touchpad...

SVN Client Error - SSL handshake failed: Secure connection truncated (url)


Encountered this annoying error all of a sudden when tried to update files from svn using Tortoise SVN client: SSL handshake failed: Secure connection truncated (url).

The failed handshake happens without logging anything. Spent some time verifying if my certificate expired or corrupted but certificate store was intact with same password. I imported the same certificate and exported back as file to test and it worked fine. File was also not corrupt if otherwise would have threw error when imported back and exported.

Followed below steps vigorously that made no difference theoretically.

1. Opened servers file from C:\Users\myname\AppData\Roaming\Subversion directory

2. Checked the certificate for expiry date and it was due after three months

4. Imported it back into the IE

5. Exported it (pfx format) in a new name with new password

6. Cleared the cache by clicking from Tortise console.

7. Commented out old ssl-client-cert-file and ssl-client-cert-password from servers file

9. Restarted the explorer before running svn operation

8. Ran svn operation to see the prompt for the certificate and password which I duly entered the new ones that I just created

Got same error even after above steps.

Next thing came to mind was to check proxy server and port. Alas! It all worked only when I commented out the proxy details from servers file. The lines with http-proxy-host and http-proxy-port details were commented and when I tested it restarting the explorer I could see files updating from svn.

Strangely, same proxy details worked when tried in IE and Chrome browser without any hassles. Though, I could not pin point on the cause of the error, issue got resolved with this one step.

SSL configuration using HP CA

This summary is not available. Please click here to view the post.

HornetQ inside OSGi Container

Recently I got chance to experiment with HornetQ message broker and idea was to run the broker as a service within OSGI container. The flexibility it offers is what impressed me along with the well proven performance.
In the process, I learnt it is possible to embed this MQ broker into any application, and that way one could completely avoid an external server to hold the broker logic. This could for sure make IT management happy where in they don't have to manage extra server just for running broker service. The implementation was a cake walk but with OSGI container in place, it called for some in depth understanding of the HornetQ architecture, as HorentQ libraries are not OSGI complaint.

To save someone's time, I thought of sharing this information on how to setup/embed HornetQ broker in an application with OSGI container.
Prerequisites : Maven, Tomcat, Apache Felix, SLF4J.
Step 1 : Download below HornetQ jars (I have used 2.0.0.GA version here).
hornetq-core.jar
hornetq-jms.jar
hornetq-logging.jar
hornetq-transports.jar
netty.3.1.0.jar
jboss-jms-api.jar

Step 2 : The above jars are not OSGI complaint (except netty.jar) and it is required to first convert them as OSGI bundles. I have used bnd tool to bundle these jars and one important note is to set the version of the bundles as 0.0.0 as it fails the auto wiring without that.

Step 3 :
After creating the bundles, we need to create a java maven project with all the above dependent bundles. Either add below configuration xmls in src\main\resoruces folder or write logic to include those configurable parameters.

hornetq-configuration.xml
hornetq-jms.xml
Step 4 :
Create Activator class and in start method write logic (give below) to start the broker service. This way as soon as bundle is started in side OSGI container, the broker starts and listens to messages in the configured port.

public void startServer(BundleContext context) {

try {

FileConfiguration configuration = new FileConfiguration();
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
String configURL = context.getBundle().getEntry("hornetq-configuration.xml").getPath();
String configRes = context.getBundle().getResource("hornetq-configuration.xml").getPath();
configuration.setConfigurationUrl(configURL);
configuration.start();
HornetQServer server = HornetQServers.newHornetQServer(configuration);
JMSServerManager jmsServerManager = new JMSServerManagerImpl(server, "hornetq-jms.xml");
jmsServerManager.setContext(null);
jmsServerManager.start();
logger.info("HORNETQ SERVER STARTED::");
}
catch (Exception e) {
logger.error(" Error starting server ",e);
}
}

Step 5:
Run maven command to compile and create bundle.

Step 6:
deploy the bundle in the OSGI container and start the bundle.

The broker should be running and now write a client to test this setup.