[Clustering/JBoss] - purgeDeadMembers Failing - what is the cause?
by jboss_cody
Hello everyone,
I have yet another issue with my cluster. I have seen this issue in other forum entries, however I am unable to locate the definite answer for it's cause.
I have a cluster which consists of 6 nodes. I have implemented fail-over and session replication within the cluster. My problem is, that when specific nodes in my cluster are stopped, their session information is not accurate when fail-over occurs.
I have investigated into each nodes logs and I have discovered that not all of my nodes have this problem.
Here is the entry from a node which does have the problem, as I called the shutdown.
| 2007-11-04 21:15:04,784 DEBUG [org.jboss.ha.framework.server.HARMIServerImpl$RefreshProxiesHATarget] replicantsChanged 'HAJNDI' to 2 (intra-view id: 56409408)
| 2007-11-04 21:15:04,860 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.jboss1] New cluster view for partition jboss1 (id: 27, delta: -1) : [192.168.202.x:1099, 192.168.202.x:1099]
| 2007-11-04 21:15:04,860 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] dead members: [192.168.202.x:1099]
| 2007-11-04 21:15:04,860 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] membership changed from 3 to 2
| 2007-11-04 21:15:04,862 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] Begin notifyListeners, viewID: 27
| 2007-11-04 21:15:04,863 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] I am (192.168.202.x:1099) received membershipChanged event:
| 2007-11-04 21:15:04,863 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] Dead members: 1 ([192.168.202.x:1099])
| 2007-11-04 21:15:04,864 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] New Members : 0 ([])
| 2007-11-04 21:15:04,864 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] All Members : 2 ([192.168.202.x:1099, 192.168.202.x:1099])
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] purgeDeadMembers, [192.168.202.x:1099]
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] trying to remove deadMember 192.168.202.x:1099 for key DCacheBridge-DefaultJGBridge
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] 192.168.202.11:1099 was NOT removed!!!
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] trying to remove deadMember 192.168.202.x:1099 for key jboss.ha:service=HASingletonDeployer
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] 192.168.202.11:1099 was NOT removed!!!
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] trying to remove deadMember 192.168.202.x:1099 for key HAJNDI
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] 192.168.202.11:1099 was NOT removed!!!
| 2007-11-04 21:15:04,864 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] End notifyListeners, viewID: 27
| 2007-11-04 21:15:05,625 INFO [org.jboss.cache.TreeCache] viewAccepted(): [192.168.202.x:33173|27] [192.168.202.x:33173, 192.168.202.x:33183]
| 2007-11-04 21:15:07,200 DEBUG [org.jboss.web.tomcat.service.session.JBossCacheManager] Looking for sessions that have expired ...
| 2007-11-04 21:15:14,362 INFO [org.jboss.cache.TreeCache] viewAccepted(): [192.168.202.x:33180|28] [192.168.202.x:33180]
| 2007-11-04 21:15:14,470 DEBUG [org.jboss.ha.singleton.HASingletonController] partitionTopologyChanged, isElectedNewMaster=true, isMasterNode=true, viewID=-424447
| 2007-11-04 21:15:14,500 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] Updating list of invalidation groups that are bridged...
|
|
Next I shutdown another node, which does not have the problem.
| 2007-11-04 21:15:14,500 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] ... nothing needs to be bridged.
| 2007-11-04 21:15:14,501 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] The list of replicant for the JG bridge has changed, computing and updating local info...
| 2007-11-04 21:15:14,501 DEBUG [org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge] ... No bridge info was associated to this node
| 2007-11-04 21:15:14,731 INFO [org.jboss.cache.TreeCache] viewAccepted(): [192.168.202.x:33178|28] [192.168.202.x:33178]
| 2007-11-04 21:15:14,744 DEBUG [org.jboss.ha.framework.server.HARMIServerImpl$RefreshProxiesHATarget] replicantsChanged 'HAJNDI' to 1 (intra-view id: -424447)
| 2007-11-04 21:15:15,078 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.jboss1] New cluster view for partition jboss1 (id: 28, delta: -1) : [192.168.202.x:1099]
| 2007-11-04 21:15:15,078 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] dead members: [192.168.202.x:1099]
| 2007-11-04 21:15:15,079 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] membership changed from 2 to 1
| 2007-11-04 21:15:15,081 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] Begin notifyListeners, viewID: 28
| 2007-11-04 21:15:15,081 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] I am (192.168.202.x:1099) received membershipChanged event:
| 2007-11-04 21:15:15,081 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] Dead members: 1 ([192.168.202.x:1099])
| 2007-11-04 21:15:15,081 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] New Members : 0 ([])
| 2007-11-04 21:15:15,081 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] All Members : 1 ([192.168.202.x:1099])
| 2007-11-04 21:15:15,081 DEBUG [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.jboss1] purgeDeadMembers, [192.168.202.x:1099]
| 2007-11-04 21:15:15,081 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.jboss1] End notifyListeners, viewID: 28
| 2007-11-04 21:15:15,571 INFO [org.jboss.cache.TreeCache] viewAccepted(): [192.168.202.x:33173|28] [192.168.202.x:33173]
|
|
I do not understand why one node is not able to be removed and the other is. My two configurations are the same. "DistributedReplicantManager" is able to remove one node, and not the other, what causes this?
Could anyone please advise as to what my problem may be?
Thank you in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101918#4101918
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101918
18 years, 5 months
[JBoss jBPM] - Token.signal() throws Exception from FieldInstantiator
by SidKennedy
Hello again :)
I have another problem. I have a processdefinition and I added some other xml-tags to a node for example as I thought that this is possible. Then I instantiate the definition, go for the RootToken and invoke signal() to start my process like this:
| process.getRootToken().signal();
|
but the following exception is thrown:
anonymous wrote :
| [ERROR] FieldInstantiator - -couldn't parse set field 'Tool' to value '<Tool xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">...' <java.lang.NullPointerException>java.lang.NullPointerException
| at org.jbpm.instantiation.FieldInstantiator.setPropertyValue(FieldInstantiator.java:70)
| at org.jbpm.instantiation.FieldInstantiator.instantiate(FieldInstantiator.java:61)
| at org.jbpm.instantiation.Delegation.instantiate(Delegation.java:163)
| at org.jbpm.instantiation.Delegation.getInstance(Delegation.java:125)
| at org.jbpm.graph.def.Action.execute(Action.java:122)
| at org.jbpm.graph.def.Node.execute(Node.java:328)
| at org.jbpm.graph.def.Node.enter(Node.java:316)
| at org.jbpm.graph.def.Transition.take(Transition.java:119)
| at org.jbpm.graph.def.Node.leave(Node.java:383)
| at org.jbpm.graph.node.StartState.leave(StartState.java:70)
| at org.jbpm.graph.exe.Token.signal(Token.java:178)
| at org.jbpm.graph.exe.Token.signal(Token.java:123)
| at myproject.workflowtools.views.WorkflowView$3.run(WorkflowView.java:214)
| at java.lang.Thread.run(Unknown Source)
|
I don't know what I can do with that information because the process is completed successfully. But I don't like exceptions as you can imagine ;) Do you have an idea what I can do?
greets
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101917#4101917
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101917
18 years, 5 months
[Installation, Configuration & DEPLOYMENT] - Re-deploy fails with exploded ear deployment
by memema
I just upgraded from JBoss tools to Red Hat Studio. One of things I noticed is that my ear file is no longer copied to the deployment directory but is extracted in the deployment directory, thus deployed in an exploded fashion.
The incremental deploy does not work for me. I can see the .class file being updated in the exploded deployment directory but changes are not reflected in the running application (until I stop/start the server).
What's worse is that when I do a 'Full publish' of my application it takes more than 5 seconds (which is JBoss' default scanperiod for the deployment dir) and JBoss tries to deploy the application which is not fully exploded yet. This results in deployment errors due to missing modules (that haven't been extracted just yet).
As a workaround I have increased the scanperiod, but I still get these errors if I do the re-deploy at the same time JBoss is polling the deployment dir.
How can I prevent JBoss to deploy an application that is being exploded?
Why does incremental deploy not work? What needs to be done to make JBoss reload the updated .class in the exploded deployment dir?
How can I go back to packaged (.ear file) deployment (so that 'Full publish' creates the .ear file and copies it to the deployment dir and does not get exploded).
Can anybody shed some light on this?
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101909#4101909
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101909
18 years, 5 months
[JBoss Seam] - 432 open unscheduled requests
by IGx89
Now that Seam 2.0.0.GA is out the door, do you plan to spend time on going over all the existing open unscheduled requests and either closing them or scheduling them for the next minor or major version or some "future version" bucket? I'm sure that would be greatly appreciated by the community; one thing I love about RichFaces is how good they are about doing that.
If you want to encourage people to find and submit bugs and continue to think up ways to improve Seam, it's very important to be consistently responsive to the issues they create. It's also important in helping show the community which direction you're planning on taking Seam, by the types of requests that get closed or get planned for future versions.
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101906#4101906
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101906
18 years, 5 months