January 2008 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by galder.zamarreno＠jboss.com

Thanks for the link, that explains better the role of pickSingleton and isElectedMaster. "bstansberry(a)jboss.com" wrote : Yes, makes sense to have the interface conform to what is actually used by external callers, with pickSingleton taking the newReplicants list. Hmmm, do you wanna keep boolean isElectedMaster(List newReplicants); or ClusterNode pickSingleton(List newReplicants); or both? In the thread link you mention, you mention: "bstansberry(a)jboss.com" wrote : I like getting Address back instead of boolean -- that way the singleton knows who the master is. I'd keep a boolean version as well though, as a convenience, i.e. | public boolean isElectedSingleton(List node) { | return pickSingleton(nodes).equals(partition.getLocalAddress()); | } | HASingletonElectionPolicy should probably only select who should ran the singleton, that's its job, and HASingletonSupport can easily decide whether the singleton selected is the clustered node where HASingletonSupport code is running or not. I'm not sure about the convenience of keeping the boolean version. By defining the boolean version in the interface as well, you are forcing people to implement it when you already know what the implementation will be. IOW, someone implementing this could provide a valid pickSingleton() implementation and an invalid implementation for isElectedMaster(). Sounds like a potential source for inconsistencies in implementations and double work vs avoiding an equals() call in HASingletonSupport. "bstansberry(a)jboss.com" wrote : First, have a look at the original discussion on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=84307 to see if anything there triggers more thinking. From that, I think I see what happened. My original idea was the policy would have a ref to HAPartition and would know the target service name (i.e. what key the replicants are under in DRM). With that a call to a simple no-args isElectedMaster() method could allow the policy to access the DRM (via HAPartition) to get the current replicants. But I think the idea that the selection was based on the replicant list rather than the view got lost. I see. So, maybe we're creating more problems for ourselves by having those setHAPartition/getHAPartition and setManagedSingleton/getManagedSingleton? Getting the List might be all we need to actually decide the singleton to run in, unless there's information that is available through DRM and not through ClusterNode that could potentially be used to make such decision at some point. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120139#4120139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120139

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by bstansberry＠jboss.com

Yes, makes sense to have the interface conform to what is actually used by external callers, with pickSingleton taking the newReplicants list. First, have a look at the original discussion on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=84307 to see if anything there triggers more thinking. From that, I think I see what happened. My original idea was the policy would have a ref to HAPartition and would know the target service name (i.e. what key the replicants are under in DRM). With that a call to a simple no-args isElectedMaster() method could allow the policy to access the DRM (via HAPartition) to get the current replicants. But I think the idea that the selection was based on the replicant list rather than the view got lost. Anyway, passing the replicant list as a method param makes more sense. If a policy impl doesn't want to use the param it doesn't have to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120123#4120123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120123

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 JDBCPersistenceManager - volunteers?

by bershath27

"timfox" wrote : | anonymous wrote : | | like to know the next steps of the process. | | | The next step would be to build a prototype and measure it's performance. ok . i will start it from my end. thanks Tyronne Wickramarathne View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120070#4120070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120070

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-4919 - ha singletons in heterogenous topologies

by galder.zamarreno＠jboss.com

Re: http://jira.jboss.com/jira/browse/JBAS-4919 and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=127194 For the moment, I'd like to focus the discussion of this JIRA in the context of JBoss 5, where we can still change the API for HASingletonElectionPolicy. As far as ha singleton election is concerned, as Brian suggested, boolean isElectedMaster(HAPartition partition); should change to boolean isElectedMaster(List<ClusterNode> newReplicants); This is the method that HASingletonSupport.partitionTopologyChanged(List newReplicants, int newViewID) calls to decide the elected master. I'm a bit concerned however about the suitability of other internal singleton selection related methods in HASingletonElectionPolicy's public API: ClusterNode pickSingleton(); | ClusterNode pickSingleton(HAPartition partition); | boolean isElectedMaster(); As far as I can see from the code, these are only used by the convenience HASingletonElectionPolicyBase class which I assume was created to make the life easier to people wanting to provide their own election policies. Users could choose not to go down this route and implement directly HASingletonElectionPolicy, which is why I don't think we should force them to implement these 3 methods as they will never be called. IMO, they should belong to HASingletonElectionPolicyBase rather than HASingletonElectionPolicy. The only relevant method users should implement is boolean isElectedMaster(List<ClusterNode> newReplicants); Regardless of the whether these 3 methods live in HASingletonElectionPolicy or HASingletonElectionPolicyBase, pickSingleton(HAPartition partition); needs changing in the same way that isElectedMaster(HAPartition partition); did to pickSingleton(List<ClusterNode> newReplicants); Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120066#4120066 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120066

18 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet Container 1.2 changes

by julien＠jboss.com

Introduced StateResponse as parent class of UpdateNavigationalStateResponse and RedirectionResponse since both classes can specify delivery of events after/before the response action is executed by the portal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120044#4120044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120044

18 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet Container 1.2 changes

by julien＠jboss.com

Renamed RenderResponse to UpdateNavigationalStateResponse since it is really what it does. That stroke me when I introduced event feature since the delivery of events can update the nav state the same way the action phase does. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120043#4120043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120043

18 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Portlet Container 1.2 changes

by julien＠jboss.com

I keep track here of the main refactorings done to the project in order to facilitate its integration in JBoss Portal 2.x project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120042#4120042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120042

18 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Branch_Stable tests broken

by ataylor

The Branch_Stable tests are failing with the trace below. I think its because the messaging-service.xml file has changed and now has 2 mbeans in it. java.lang.ClassNotFoundException: jboss.messaging:service=SecurityStore | at java.net.URLClassLoader$1.run(URLClassLoader.java:200) | at java.security.AccessController.doPrivileged(Native Method) | at java.net.URLClassLoader.findClass(URLClassLoader.java:188) | at java.lang.ClassLoader.loadClass(ClassLoader.java:306) | at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.test.messaging.tools.container.ServiceContainer.type(ServiceContainer.java:294) | at org.jboss.test.messaging.tools.container.ServiceContainer.setAttribute(ServiceContainer.java:748) | at org.jboss.test.messaging.tools.container.ServiceContainer.registerAndConfigureService(ServiceContainer.java:703) | at org.jboss.test.messaging.tools.container.LocalTestServer.startServerPeer(LocalTestServer.java:336) | at org.jboss.test.messaging.tools.container.LocalTestServer.start(LocalTestServer.java:150) | at org.jboss.test.messaging.tools.container.RMITestServer.start(RMITestServer.java:150) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) | at sun.rmi.transport.Transport$1.run(Transport.java:153) | at java.security.AccessController.doPrivileged(Native Method) | at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) | at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) | at java.lang.Thread.run(Thread.java:595) | at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) | at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) | at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) | at org.jboss.test.messaging.tools.container.RMITestServer_Stub.start(Unknown Source) | at org.jboss.test.messaging.tools.ServerManagement.start(ServerManagement.java:204) | at org.jboss.test.messaging.tools.ServerManagement.start(ServerManagement.java:188) | at org.jboss.test.messaging.tools.ServerManagement.start(ServerManagement.java:181) | at org.jboss.test.messaging.tools.ServerManagement.start(ServerManagement.java:176) | at org.jboss.test.messaging.jms.JMSTestCase.setUp(JMSTestCase.java:83) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119990#4119990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119990

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - AnnotationMetaDataDeployer queries isMetadataComplete on JBo

by wolfc

http://jira.jboss.com/jira/browse/JBAS-5136 I have taken the naive approach and defer to the EjbJarMetaData attachment. But we might want to take a different merge approach. So the question is whether to apply the JBAS-5136.patch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119984#4119984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119984

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Extendable Transports List

by acure

I have to give new internal transport add possibility. We have a few groups working on projects based on jbossesb with our additions, and specific project's requirements force us to implement new internal transports :/. This is a reason that we have to do as fast as possible - that means "ourself". Acure View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119929#4119929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119929

18 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008