Jboss 4.2.1 clustering bug ?

[islpe]

I am currently involved in a migration of web applications from single Jboss 3.2.2 to Jboss 4.2.1 cluster version. I need to deploy an application as a singleton, so I want to deploy it to deploy-hasingleton directory in the all configuration. When the application is deployed in deploy directory, the application runs without problems, like in Jboss 3.2.2. When the application is removed from deploy directory and deployed in deploy-hasingleton directory instead, the application starts up, but when I try to get a html page, I get an error:

org.apache.cocoon.ProcessingException: Lookup of serializer for role 'html' failed.:

While surfing on the net I came across the problem in http://www.mail-archive.com/[e-mail]/msg20943.html//www.mail-archive.com/[e-mail]/msg20943.html. But there is apparently no reply

The application uses Cocoon 2.1.3 and I have spent a lot of time trying to figure out what could cause the error. I am about to raise a bug report against Jboss 4.2.1, but would like to see if any one can help me out.

Lasse Petersen

[brian.stansberry]

Is everything your application needs all packaged together in whatever you put in deploy-hasingleton?

I have no idea about Cocoon internal or what it's doing in that call. But if your application is entirely self-contained, there should be no difference in its ability to find resources from deploying it via deploy-hasingleton vs. deploy.

Don't file a bug until we get establish what it is we're talking about.

[islpe]

The application is a war file and reads EDI files and applies these as updates to the database. There are few html pages where you can 'take the temperature' of the application, and it is on these pages that the error occurrs.

One difference between Jboss 3.2.2 and jboss 4.2.1 is the use of Avalon framework. This is in 4.2.1 placed in lib directory whereas it was not present in 3.2.2. Since Cocoon uses Avalon framework I had to use isolation(http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration, updated jboss-web.xml and this made the application run as it should in deploy directory under 4.2.1. Here are the scenarios I have tried. All have been deployed in deploy-hasingleton

1) Put the war file in deploy-hasingleton, as it is described in the Jboss Clustering Guide. The error occurred and this is shown in the log

Only the root deployment can set the loader repository, ignoring config=LoaderRepositoryConfig(repositoryName: jboss.dataintegration:war=dataintegration.war, repositoryClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig: java2ParentDelegation=false)

but according to 'http://wiki.jboss.org/wiki/Wiki.jsp?page=GetWARNquotOnlyTheRootDeploymentCanSetTheLoaderRepositoryquotOn3.2.5', this can be ignored

2) Created a SAR and a jboss-service.xml with isolation and and an mbean containing HASingletonController. The same error occurred, but again this is shown in the log
Only the root deployment can set the loader repository, ignoring config=LoaderRepositoryConfig(repositoryName: jboss.dataintegration:sar=dataintegration.sar, repositoryClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig: java2ParentDelegation=false)

for both sar and war

3) Created a SAR and a jboss-service.xml with isolation and and an mbean containing HASingletonController but this time the isolation in jboss-web.xml in the war file is removed. The same error occurred, but again this is shown in the log:

Only the root deployment can set the loader repository, ignoring config=LoaderRepositoryConfig(repositoryName: jboss.dataintegration:sar=dataintegration.sar, repositoryClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig: java2ParentDelegation=false)


I think it is odd that each time the application is deployed in deploy-hasingleton and fails, the text about root deployment that can be ignored, is showing.

I used to think that this problem wa related to classpath, but I am not so sure


Lasse Petersen

[brian.stansberry]

Try deploying you war in deploy, no sar or HASingletonController, with your classloader isolation in jboss-web.xml. That is, the way it works. But add to jboss-web.xml a depenedency on the HASingleton BarrierController as described at http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Clustering_Guide/beta422/html/ch05s11s03.html

From a quick look, seems like the Avalon dependency is being pulled in via the IIOP module's use of Jacorb. Another possible approach is disabling use of IIOP (if you don't need it), but I've never done that and can't say how much of a ripple effect it might have.

[islpe]

Thanks for the suggestion

I have done as you and the doc described and the application starts nicely up and no error occurred. But the real test comes when I deploy it into the cluster next week. I will get back with the result

Lasse Petersen

[islpe]

The service deploy-hasingleton.service does exactly what we want, and since your first proposal does not offer this, we decided to try out your second proposal: removing avalon from jboss/lib and remove iiop_service.xml from deploy directory.

This has so far been working. Jboss as well as the application starts up, and I can get the html pages from our application. We have not yet done a thorough testting, bu we will do so.

My conclusion is that while class isolation works when the application is deployed in deplo directory, it does not work when deployed in deploy-hasingleton directory. To me that sounds like a bug.

[islpe]

and the message in the log about 'Only the root deployment..,' that can be ignored is invalid in this situation

[brian.stansberry]

"islpe" wrote:

My conclusion is that while class isolation works when the application is deployed in deplo directory, it does not work when deployed in deploy-hasingleton directory. To me that sounds like a bug.

Agreed. http://jira.jboss.org/jira/browse/JBAS-5284

Please be sure and post back on how your testing of the barrier controller approach works.