-
1. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
pferraro Dec 16, 2009 2:27 PM (in response to j_ri)First of all, the quick-start guide still reflects the latest stable release (1.0.2).
In 1.1.0.Beta1, the AS configuration structure has changed somwehat.
In general, the delegateBeanName referenced in your mod_cluster lifecycle listener defined in server.xml must match the name of the bean of type org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter in mod_cluster-jboss-beans.xml.
e.g.
server.xml:
{code:xml}<Listener className="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" delegateBeanName="ModClusterListener"/>{code}
mod_cluster-jboss-beans.xml:
{code:xml}<bean name="ModClusterListener" class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" mode="On Demand">
<constructor>
<parameter><inject bean="ModClusterService"/></parameter>
</constructor>
</bean>{code}
As for the initial error you got - I've filed a jira:
https://jira.jboss.org/jira/browse/MODCLUSTER-116
In summary, ModClusterService contains 2 constructors containing 2 parameters - and sometimes the microcontainer gets confused about which one to use. This behavior is described in more details here:
http://www.jboss.org/file-access/default/members/jbossmc/freezone/docs/2.0.x/userGuide/ch10s02.html
To remove this ambiguity, you'll need to add explicit types to the constructor parameters, matching the types of the expected arguments.
e.g.
{code:xml}<bean name="ModClusterService" class="org.jboss.modcluster.ModClusterService" mode="On Demand">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.web:service=ModCluster",exposedInterface=org.jboss.modcluster.ModClusterServiceMBean.class)</annotation>
<constructor>
<parameter type="org.jboss.modcluster.config.ModClusterConfig"><inject bean="ModClusterConfig"/></parameter>
<parameter type="org.jboss.modcluster.load.LoadBalanceFactorProvider"><inject bean="DynamicLoadBalanceFactorProvider"/></parameter>
</constructor>
</bean>{code}You indicated that you wish to use HAModClusterService instead of ModClusterService.
To do this, simply change the name of the bean reference in ModClusterListener.
e.g.
{code:xml}<bean name="ModClusterListener" class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" mode="On Demand">
<constructor>
<parameter><inject bean="HAModClusterService"/></parameter>
</constructor>
</bean>{code}
-
2. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
j_ri Dec 22, 2009 5:17 AM (in response to pferraro)Hello Paul,
thanks for the answer. But unfortunately I still can't get the thing running.
This is what I configured in server.xml:
{code:xml}<Listener className="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" delegateBeanName="ModClusterListener"></Listener>{code}
In mod_cluster-jboss-beans.xml I did the following:
first try:
{code:xml}<bean name="ModClusterListener" class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" mode="On Demand">
<constructor>
<parameter><inject bean="ModClusterService"/></parameter>
</constructor>
</bean>{code}second try:
{code:xml}<bean name="ModClusterListener" class="org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter" mode="On Demand">
<constructor>
<parameter type="org.jboss.modcluster.ModClusterService"><inject bean="ModClusterService"/></parameter>
</constructor>
</bean>{code}while the ModClusterService was configured like that:
{code:xml}<bean name="ModClusterService" class="org.jboss.modcluster.ModClusterService" mode="On Demand">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.web:service=ModCluster",exposedInterface=org.jboss.modcluster.ModClusterServiceMBean.class)</annotation>
<constructor>
<parameter type="org.jboss.modcluster.config.ModClusterConfig"><inject bean="ModClusterConfig"></inject></parameter>
<parameter type="org.jboss.modcluster.load.LoadBalanceFactorProvider"><inject bean="DynamicLoadBalanceFactorProvider"></inject></parameter>
</constructor>
</bean>{code}This results to the following error message:
java.lang.InstantiationException: org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at org.jboss.web.tomcat.service.deployers.TomcatService.getInstance(TomcatService.java:375)
at org.jboss.web.tomcat.service.deployers.TomcatService.addLifecycleListeners(TomcatService.java:410)
at org.jboss.web.tomcat.service.deployers.TomcatService.startService(TomcatService.java:201)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:243)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
at sun.reflect.GeneratedMethodAccessor257.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1570)
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1535)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
at sun.reflect.GeneratedMethodAccessor257.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1570)
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1535)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:619)Do you have any more ideas?
Thanks
Jochen
-
3. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
pferraro Dec 23, 2009 9:42 AM (in response to j_ri)The listener in your server.xml should be:
{code:xml}
<Listener className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener"
delegateBeanName="ModClusterListener"/>{code}
Use this with the ModClusterListener bean configuration from your "first try". The parameter type indicated in your second try does not match the constructor signature of CatalinaEventHandlerAdapter. Since there is only one constructor for this class, you don't need to define a parameter type. -
4. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
j_ri May 31, 2010 5:27 AM (in response to pferraro)Hello,
sorry for not answering any more for a while. I had other priorities;-(
Mean while I managed to get version 1.1.0.CR1 working. I've used it on a littel test cluster for about three weeks now. Unfortunately it is not stable. After my cluster was running about 3 or 4 days, suddenly httpd just answers with "object not found -- error 404".
If I restart Apache2 everything is fine again. There's not need to restart the JBoss nodes.
Then today I wanted to update to 1.1.0.CR2. And I think I found a bug:
With the new "mod_cluster.sar" my JBoss didn't start any more, because of this error:
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "ModClusterListener" is missing the following dependencies:
Dependency "WebServer" (should be in state "Create", but is actually in state "Configured")Then I tried to remove
<depends>WebServer</depends>
from the bean
<bean name="ModClusterListener" ....
and now CR2 is working!;-)
And this is somwhow obvious.
On http://www.jboss.org/mod_cluster/java/config.html is said that this configuration should be done
<bean name="WebServer" class="org.jboss.web.tomcat.service.deployers.TomcatService">
<!-- ... -->
<depends>ModClusterListener</depends>
<!-- ... -->
</bean>
but then in the CR2 version of mod_cluster-jboss-beans.xml the ModClusterListener bean depends on "WebServer". Isn't this a cyclic-refence?
Thanks,
Jochen -
5. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
pferraro Jun 3, 2010 10:16 AM (in response to j_ri)While the way you've configured the dependencies will work, it will not be the default setup in JBoss AS 6.0.0.M4 and beyond.
One of the changes in mod_cluster 1.1.0.CR2 was support for the reversal of dependency between the ModClusterListener and WebServer beans.
Starting with AS 6.0.0.M4 (this is already implemented in AS trunk), the ModClusterListener bean from mod_cluster.sar will depend on the WebServer bean in jbossweb., not the other way around. This has a couple consequences:
1. mod_cluster will work out of the box. There will no longer be any post-installation config changes (e.g. adding a dependency to jbossweb) necessary to get mod_cluster to work in with JBoss AS. You'll be able to start a vanilla JBoss instance with -Djboss.mod_cluster.advertise=true or -Djboss.mod_cluster.proxyList=... and have instant mod_cluster support.
2. mod_cluster will now start *after* jbossweb. It can be stopped, restarted, or even undeployed without affecting jbossweb.
The docs need updating - that's on my to do list.
-
6. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
j_ri Jun 11, 2010 3:20 AM (in response to pferraro)Ah, I see. Thank you.
Do you have an idea what could be the reason that mod_cluster works perfectly the whole day....but the next morning none of the applications is reachable and the mod_cluster-manager shows no available nodes?
After restarting Apache2 everything works fine again...until the next morning;-(
I tried different OPTION settungs in my virtual host, but all I changed is the error message in the apache error log. After putting a "index.html" file in the "/srv/www/htdocs" folder I didn't get an error mesaage for indexing any more. Now I only get messages like
[Fri Jun 11 07:32:12 2010] [error] [client xxx.xxx.xx.xx] File does not exist: /srv/www/htdocs/favicon.ico
or
[Fri Jun 11 07:48:24 2010] [error] [client xxx.xxx.xx.xx] File does not exist: /srv/www/htdocs/<application name>
in the Apache2 log-files.
So it seems that Apache doesn't forward any more to the JBoss nodes but just tried to deliver plain files from its standard folder.
In the log-files of my JBossAS instances I don't find any suspicious messages.
I don't know what to try next to solve this behaviour.....
-
7. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
jfclere Jun 14, 2010 4:51 AM (in response to j_ri)there should error messages in error_log before the "File does not exist:..."
-
8. Re: mod_cluster 1.1.0 Beta1 with JBoss EAP 5.0.0
j_ri Jun 14, 2010 5:12 AM (in response to jfclere)I'll attach the logfile "error_log" from yesterday evening to this morning.
See the error in line 921
[Mon Jun 14 08:36:52 2010] [error] [client 150.131.31.109] File does not exist: /srv/www/htdocs/portal
where "portal" is the name of one of our applications in the root "/" context of the JBoss cluster nodes.
-
error_log.zip 15.8 KB
-