Relocate svn repo?
by Paul Ferraro
Today, Jean-Frederic and I discussed creating an svn branch for 1.0.x
work so that work on 1.1 can proceed in trunk. However, this brings up
another issue...
Currently, we share our subversion repository with the jboss native
project. Our source code resides in an awkward subdirectory of trunk,
making branching (not to mention the maven release process) equally
awkward. Now would seem to be as good a time as any to move to our own
repository. How would this impact the build of the native side? If we
keep its current location, should this branch only copy from
trunk/mod_cluster? Thoughts?
Paul
14 years, 11 months
ClastCastException on redeployment of mod-cluster.sar
by Bela Ban
When I touched mod-cluster.sar/META-INF/mod-cluster-jboss-beans.xml, I
got the exception below.
Can someone look into this ?
2009-07-31 09:52:40,084 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/invoker
2009-07-31 09:52:40,168 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/juddi
2009-07-31 09:52:40,170 INFO
[org.apache.juddi.registry.RegistryServlet] (HDScanner) jUDDI Stopping:
Cleaning up existing resources.
2009-07-31 09:52:40,172 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/jbossws
2009-07-31 09:52:40,176 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/web-console
2009-07-31 09:52:40,182 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/admin-console
2009-07-31 09:52:40,186 INFO
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner)
undeploy, ctxPath=/jmx-console
2009-07-31 09:52:40,225 INFO [org.apache.coyote.http11.Http11Protocol]
(HDScanner) Pausing Coyote HTTP/1.1 on http-10.254.203.178-8080
2009-07-31 09:52:40,230 INFO [org.apache.coyote.http11.Http11Protocol]
(HDScanner) Stopping Coyote HTTP/1.1 on http-10.254.203.178-8080
2009-07-31 09:52:40,231 INFO [org.apache.coyote.ajp.AjpProtocol]
(HDScanner) Pausing Coyote AJP/1.3 on ajp-10.254.203.178-8009
2009-07-31 09:52:40,236 INFO [org.apache.coyote.ajp.AjpProtocol]
(HDScanner) Stopping Coyote AJP/1.3 on ajp-10.254.203.178-8009
2009-07-31 09:52:40,292 INFO [org.apache.catalina.core.StandardService]
(HDScanner) Stopping service jboss.web
2009-07-31 09:52:41,506 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController]
(HDScanner) Error installing to Start: name=HAModClusterService
state=Create mode=On Demand requiredState=Installed
java.lang.ClassCastException:
org.jboss.modcluster.ha.ModClusterServiceDRMEntry cannot be cast to
org.jboss.modcluster.ha.ModClusterServiceDRMEntry
at
org.jboss.modcluster.ha.HAModClusterService.narrowCandidateList(HAModClusterService.java:496)
at
org.jboss.modcluster.ha.HAModClusterService.getElectionCandidates(HAModClusterService.java:477)
at
org.jboss.ha.framework.server.HASingletonImpl.election(HASingletonImpl.java:206)
at
org.jboss.ha.framework.server.HASingletonImpl.elected(HASingletonImpl.java:199)
at
org.jboss.ha.framework.server.HASingletonImpl.partitionTopologyChanged(HASingletonImpl.java:162)
at
org.jboss.ha.framework.server.HASingletonImpl.registerDRMListener(HASingletonImpl.java:124)
at
org.jboss.ha.framework.server.HAServiceImpl.start(HAServiceImpl.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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:241)
at
org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
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:1631)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
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.GeneratedMethodAccessor252.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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:286)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1568)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1533)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:943)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
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.GeneratedMethodAccessor252.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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:286)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1568)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1533)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:943)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
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:1439)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
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.hotdeploy.HDScanner.scan(HDScanner.java:362)
at
org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
2009-07-31 09:52:41,530 WARN
[org.jboss.system.server.profileservice.hotdeploy.HDScanner] (HDScanner)
Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of
incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
DEPLOYMENTS IN ERROR:
Deployment "HAModClusterService" is in error due to the following
reason(s): java.lang.ClassCastException:
org.jboss.modcluster.ha.ModClusterServiceDRMEntry cannot be cast to
org.jboss.modcluster.ha.ModClusterServiceDRMEntry
at
org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
at
org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128)
at
org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:369)
at
org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
14 years, 11 months
VirtualHost in httpd.conf
by Bela Ban
In the sample config, we create a VirtualHost, e.g:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
Listen 10.33.144.3:6666
<VirtualHost 10.33.144.3:6666>
<Directory />
Order deny,allow
Deny from all
Allow from 10.33.144.
</Directory>
KeepAliveTimeout 60
MaxKeepAliveRequests 0
ManagerBalancerName mycluster
AdvertiseFrequency 5
</VirtualHost>
Is this necessary ? If I don't want to define KeepAliveTimeout,
MaxKeepAliveRequests, ManagerBalancerName or AdvertizeFrequency, do I
need VirtualHost, or can I just remove it ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
15 years
nullpointer exception while updating cluster status
by Marek Goldmann
Hi,
I got today a NullPointerException:
java.lang.NullPointerException at
org.jboss.modcluster.ha.HAModClusterService
$
ClusteredCatalinaEventHandler
.updateClusterStatus(HAModClusterService.java:896) at
org.jboss.modcluster.ha.HAModClusterService
$ClusteredCatalinaEventHandler.status(HAModClusterService.java:836) at
org.jboss.modcluster.ha.HAModClusterService
$ClusteredCatalinaEventHandler.status(HAModClusterService.java:781) at
org
.jboss
.modcluster
.CatalinaEventHandlerAdapter
.lifecycleEvent(CatalinaEventHandlerAdapter.java:157) at
org
.apache
.catalina
.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at
org
.apache
.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:
1348) at org.apache.catalina.core.ContainerBase
$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1612)
at org.apache.catalina.core.ContainerBase
$ContainerBackgroundProcessor.run(ContainerBase.java:1601) at
java.lang.Thread.run(Thread.java:636)
JBoss AS log is here: http://pastie.org/560597
What could be the reason for that? I'm using mod_cluster 1.0.0.GA.
--
Marek Goldmann
JBoss by Red Hat
15 years
mod_cluster manager and terminated nodes
by Marek Goldmann
Proposing an enhancement for mod_cluster manager: I think that
mod_cluster manager should remove not running (terminated, crashed)
nodes from node list.
I'm using mod_cluster on EC2: I'm starting/shutting down instances.
After a few such operations I don't know which nodes are really
running and which are only ghosts.
Or maybe I just misconfigured mod_cluster?
--
Marek Goldmann
JBoss by Red Hat
15 years
Session temporarily unavailable
by Bela Ban
When I have 2 nodes (node1, node2), and a session which is created on
node1 (and replicated to node2), the following can happen:
* I shut down node1 (CTRL-C)
* node1 terminates cleanly
* I access the webapp, but get a "Session temporarily unavailable"
failure message (I guess a 500)
* When I check mod-cluster-manager, information about node1 is still
there !
* Ca 5 seconds later, mod-cluster-manager doesn't show node1 anymore
* When I now access the webapp, I get the proper failed over session
on node2 and all my data is still there
So my question is why doesn't node2 immediately tell httpd/mod-cluster
that node1 is gone ? It seems that httpd *itself* only learns about this
when it pings the socket to node1...
I recall Paul once telling me we hadn't implemented that functionality,
but I guess by now this is surely implemented ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
15 years
mod-cluster and domains with sticky sessions
by Bela Ban
OK, I read through the archives of this list and came up with a solution
for mod-jk, but apparently nobody has so far used domains/sticky
sessions with *mod-cluster* !
I found 2 different ways of doing this:
#1 server.xml:
---------------------
<Listener className="org.jboss.modcluster.ModClusterListener"
advertize="true" domain="${jboss.Domain:DefaultDomain}" />
#2 and in mod-cluster-jboss-beans.xml:
---------------------------------------------------------
<bean name="HAModClusterService" ...>
<property name="domain">${jboss.Domain:DefaultDomain}</property>
</bean>
and then started several instances:
./run.sh -b 192.168.1.5 -c all -g *D1* -u 230.1.1.1 -m 10500
-Djboss.jvmRoute=*node1* -Djboss.Domain=*D1*
./run.sh -b 192.168.1.9 -c all -g *D1* -u 230.1.1.1 -m 10500
-Djboss.jvmRoute=*node2* -Djboss.Domain=*D1*
and
./run.sh -b 192.168.1.10 -c all -g *D2* -u 230.2.2.2 -m 11500
-Djboss.jvmRoute=*node3* -Djboss.Domain=*D2*
So we have domains D1 (cluster D1 with node1 and node2) and D2 (cluster
D2 with node3).
#1 above seems to work half way, #2 doesn't.
Questions
========
* What is the recommended way of setting of domains ?
o I assume #1, but that's not documented anywhere, I just
found out accidentally through a port via google
* Sometimes, a webapp on node2 fails over to node3 rather than node1
Can someone look into this ? This information should be available via a
web page, similar to the one for mod-jk !
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
15 years
Invalidation bug
by Bela Ban
Here's another one:
* Nodes node1 and node2 running
* I disable (via mod-cluster-manager) all contexts on node2
* I open a new browser and connect to my webapp via httpd
* --> The resulting page is empty !
* --> I expected to get my session created on node1 !
* When I re-enable all contexts on node2, this works
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
15 years
