Running LSDS 7.1 on Websphere: using Parent Last class loader order, etc.

A thread I started about LiveSite on zLinux has unearthed some useful information about running LSDS on WAS, which I wanted to separate out... :

If you are using WAS (I am assuming this since you are looking at the IBM linux distro), you should have an admin that is familiar with their configuration (WAS is far from trivial to configure and tune); WAS which uses their own version of common open source libraries which have been branched by IBM and no longer fully compatible (Xalan, Xerces, et al), so extra configuration steps are required to make sure the correct open source libraries are visible to the WAR (PARENT_LAST must be set at the very least) and IBM ones are not picked up (since they removed Serialization from their version for some odd reason and prevent the caches from working). Another issue is with logging, WAS uses their own version of log4j which again is not compatible with open source version and you have to configure logging to correctly get it to work (we have a document that explains this so it is something to be aware of).

Another issue you should be aware of with WAS is that when it starts it uses roughly 400MB of RAM without anything loaded, so you will need to size memory on the high side to account for this (there are a lot of "services" included with WAS that you may or may not need but they get loaded anyways).

PS: I was very interested by your comments on IBM modifications of Open Source packages etc. Even though we strictly followed the install guide when installing LSDS 7.1 on WAS 7.0 (ls_71_runtime_install_v01_en.pdf), I'm noticing several java.io.NotSerializableException messages in the logs (in code called by org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache). I guess I may need to make a separate post about that.

NotSerializable is the result of IBM libraries loaded before open source ones, you must have PARENT_LAST set on the classloader config for things to work.

As I said, we strictly followed the install guide when installing LSDS 7.1 on WAS 7.0 (ls_71_runtime_install_v01_en.pdf), and on p.82 it says: "Choose Parent First from the Class loader mode drop-down list.". (while the screenshot shows the dropdown with Parent Last highlighted)

switching to Parent Last seems to have resolved our NotSerializable errors in stdout log.

Find more posts tagged with

Comments

Frederik

I created Support Case #775412 for this docbug.

Frederik

****, I'm back to getting NotSerializableException errors in the logs. Smiley Sad

Not sure why... when I visit the site, I don't get them... They are in the log from some other visitor on my test site. Maybe I need a way to bypass the in-memory cache to reproduce more consistently?

[5/19/10 12:42:04:334 MEST] 00000087 IndexedDiskCa E org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache processUpdate Region [component] Failure updating elemen
t, key: install-validation-component-guide:Analytics Integration/WebTrends Analyticsrimary:en:1208117652742efault HTML old: null
                                 java.io.NotSerializableException: org.apache.commons.logging.impl.Jdk14Logger
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at java.util.LinkedList.writeObject(LinkedList.java:943)
        at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
        at org.apache.jcs.utils.serialization.StandardSerializer.serialize(StandardSerializer.java:54)
        at org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache.processUpdate(IndexedDiskCache.java:513)
        at org.apache.jcs.auxiliary.AbstractAuxiliaryCacheEventLogging.updateWithEventLogging(AbstractAuxiliaryCacheEventLogging.java:48)
        at org.apache.jcs.auxiliary.disk.AbstractDiskCache.doUpdate(AbstractDiskCache.java:828)
        at org.apache.jcs.auxiliary.disk.AbstractDiskCache$MyCacheListener.handlePut(AbstractDiskCache.java:685)
        at org.apache.jcs.engine.CacheEventQueue$PutEvent.doRun(CacheEventQueue.java:704)
        at org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent.run(CacheEventQueue.java:623)
        at org.apache.jcs.engine.CacheEventQueue$QProcessor.run(CacheEventQueue.java:591)

Frederik

I know I'm talking to myself here... but maybe one day somebody can use this...

we found the reason for the continuing NotSerializableException errors:

- we had set the Application (LiveSite Run Time.ear) to PARENT_LAST,
- but we had kept other default values, including having a separate Class Loader per Web Module.
- and on the Web Module (iw-runtime.war), it was still the default PARENT_FIRST class loading order.

So, we set the Application (LiveSite Run Time.ear) to PARENT_LAST + single Class Loader => bingo. Cache ok.

buuuuuuuutttt.... now we get some java.lang.LinkageError in a few pages of the Component Guide. phhhh

:mad:

Edit:
ooh, jeezzz... frustration upon frustration: trying to upload a screenshot of WAS 7 admin console failed:
error: File Too Large. Limits are 620 x 280. Your file is 509 x 468.
Are you kidding me?

AlexC

This information should have been in the WAS installation guide, was a part of it missing?

Frederik

Alex:
yes, part of that info is missing.

looking at ls_71_runtime_install_v01_en.pdf about WAS install,

p.82 says to set the Application (LiveSite Run Time.ear) to PARENT_FIRST (should be PARENT_LAST) - as discussed above

and it doesn't mention at all to set single Class Loader for the Application

The combination of the defaults:
- LiveSite Run Time.ear: 'classloader for each WAR in the application'
- Web Module (iw-runtime.war): PARENT_FIRST

still gives an effect of PARENT FIRST for the iw-runtime.war and breaks the cache.

Frederik

while I'm on the subject...

With PARENT_LAST correctly set on our LSDS on WAS 7, we get some java.lang.LinkageError in the Component Guide site (the demo site included with SP/LS 7.1 and earlier). The potential for such error is flagged by the context help of the WAS Admin Console:

Class loader order
Specifies whether the class loader searches in the parent class loader or in the application class loader first to load a class. The standard for development kit class loaders and WebSphere® Application Server class loaders is Classes loaded with parent class loader first. By specifying Classes loaded with local class loader first (parent last), your application can override classes contained in the parent class loader, but this action can potentially result in ClassCastException or LinkageErrors if you have mixed use of overridden classes and non-overridden classes.

Here the error we get

java.lang.LinkageError: loader constraint violation: loader (instance of com/ibm/xtq/xslt/jaxp/compiler/TransformerFactoryImpl$ByteCodeArraysClassLoader) previously initiated loading for a different type with name "javax/xml/namespace/QName"

So far I've seen this on 2 pages of the Component Guide.

Digital Asset/Flash/Advanced Flash
Developer Tool/Testing/Display HTTP Header

The LSDS is fresh installed on WAS7, the Component Guide is untouched (just copied into a test branch), and only the foundation.jar and oracle ojdbc14.jar added to WEB-INF.

Frederik

attaching part of our SystemOut.log with the stacktrace of java.lang.LinkageError. Had to respect a filesize limit of 19k on the forum, so not too much context.

Frederik

Alex,

I noticed that the following 4 XML-related libraries are added to the $tomcat/endorsed folder by the LSDS graphical installer.

serializer.jar
xalan.jar
xercesImpl.jar
xml-apis.jar

In the "installation on Websphere" instructions, nothing is being said about those JARs. Are we meant to put these somewhere accessible to Websphere?

AlexC

Our QA did the install documentation for WebSphere so I am not sure if that was included, but the 'endorsed' directory needs to be added to the JRE 'lib' directory with those 4 jar files; however I do not know about WebSphere, IBM does a lot of irregular things with jars and who knows if it will run if you override their own branched non-standard versions of the open source jars.