OWSM: Loading private and public certifcates

As written in my blog article on SSL, handling certificates is not easy. One of the goals I had was to load a public and private certificate into a JKS key-store. With tools such as keytool and openssl, this is not possible. After struggeling a few hours, I managed to fix this. This is how I did it.

You have two files, one public key and one private key; vijfhuizen_pub.pem, vijfhuizen_prv.pem. Based on these files, you can load the keystore as follows:

• Convert the keys into DER format.
• Load the DER files into a new keystore via Java.

Example:

openssl x509 -in vijfhuizen-pub.pem -inform PEM -out vijfhuizen-pub.crt -outform DER

openssl pkcs8 -topk8 -nocrypt -in vijfhuizen-prv.pem -inform PEM -out vijfhuizen-prv.crt -outform DER

java ImportKey -prikey vijfhuizen-prv.crt -signed vijfhuizen-pub.crt -alias vijfhuizen -keypass changeit -store vijfhuizen.jks

De Java Class has the following options:

java ImportKey
Usage

    java ImportKey -alias alias -prikey file.der -signed cert.der -keypass pas1 -storepass pas2
    java ImportKey -alias alias -prikey file.der -signed cert.der -keypass pas1 -store file.jks -storepass pas2

Description

    Store DER key and signed certificate into user's home key store, or into the key
    store file specified by the STORE parameter.

The Java  code can be download here.

OSB: Deployment issues with DBAdapter

In normal circumstances changing the configuration of the DBAdapter should work. You create a JDBC datasource and create in the outbound connections of the DbAdpater a new JNDI entry. After saving your settings you should update the DBAdapter application and apply the changes. Normally you see:





Here is the issue I was struggeling with. I created a new JNDI entry in the DBAdapter, applied the changes, deployed the Plan.xml files, updated the DBAdapter. I saw that the managed servers did not picked up the new change or even the old entries.

After a while I fixed the issue. This was related due to the fact the DbAdapter was also targed to the AdminServer. So here are the steps to update or add new JNDI entries in the DbAdapter application or any other, AqAdapter or FileAdapter.

1. Update/Add JNDI entry in your outbound connections of the Adapter.
2. Save the changes.
3. Bring down the Managed Servers.
4. Update the Adapter application.
5. Bring down the Admin Server.
6. Copy the Plan.xml file of the Adapter to the managed servers.
7. Start the AdminServer.
8. Start the managed servers.

This solution is strange, because you expect that Weblogic should do this while the AdminServer and Managed Servers are running. But in my case this was a working solution.

To create and deploy your own Adapters can be found @Edwin Biemond's Blog.

OSB: AdminServer spinning 100% CPU

Sometimes for no reason, or I did not find a reason..., the AdminServer is spinning into 100% CPU. Communication is impossible; deployment is failing or take a long time (hours...), Console will not start, etc.

The log files of the AdminServer will not give you a hint on this behavior. It will tell you that memory is reaching 100%:

AdminServer.log: reaching out of memory

Kill the AdminServer process and starting the AdminServer again, will not solve the issue. After a time the AdminServer is at 100% and communication is not possible.

A solution that worked for a short time was:

kill AdminServer process
delete all files and directories from the AdminServer:

cd $WLS_DOMAIN/servers/

cp -rv AdminServer/security .

rm -rf AdminServer/*

mv security AdminServer

Start the AdminServer

This solution resulted taht teh AdminServer was up and running, I could connect to the Service Bus console and the normal console. But when I started a deployment of new services, the AdminServer spinned into 100%.

After searching the log files and investigating why this suddenly happened, it did not occur on other environments, I did something radical. I removed all the OSB artifacts that were installed on the the AdminServer.

stop AdminServer
stop all the managed servers

cd $WLS_DOMAIN/osb

rm -rf *

start AdminServer

Now the AdminServer is up and running very quickly. Due to the fact there are now services deployed.

Start a deployment of services to the AdminSerer
After deployment, start all the managed services.

This workarround works! The AdminServer is not spinning anymore, reacts fast on the consoles.

SOA 11g: Improved Memory and Garbage Consumption

There is a huge difference in memory consumption when you run SOA11g (PS4 in my case). The screens are based on a full-production clustered environment. One node is running with sub-optimal settings, while the other node is running optimal settings. A load-balancer is equally spreading the requests to the nodes.

Running SOA 11g on VMWare, 1 CPU and 3GB memory, with the options:

-Xms1280m
-Xmx1280m
-XX:MaxPermSize=512m
-XX:+UseParallelGC



Running SOA 11g on VMWare, 1 CPU and 3GB memory, with the options:

-Xms1280m
-Xmx1280m
-XX:MaxPermSize=512m
-Xss256k
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing



The last XX options shows that the memory consumption is dramaticlly lower and garbage collection is lower but frequenter.