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

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling of 'deployments taking ~1 minute' scenario

by bstansberry＠jboss.com

IIRC, the 1 min deployment scenario was due to a deadlock where the AS code used the JGroups up_handler to make an RPC, thus preventing the RPC response from arriving. Wasn't this a bug that was fixed? In that case, it was the node sending the RPC that was faulty. In some other case where a remote node "isn't responding" all you could do would be to send a message to "commit suicide" -- there's no mechanism to evict a node from the group outside of JGroups' own failure detection. But if the node isn't responding to RPCs, it likely wouldn't respond to the "commit suicide" either. Logically, I could see some benefit in some sort of self-healing approach where cluster members detect faults and restart themselves or send commands to others telling them to restart. But this will take a lot of thought. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120188#4120188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120188

18 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS brings Metro/CXF but in what version?

by thomas.diesler＠jboss.com

anonymous wrote : | Question: if an end-user wishes to use the CXF flavor of JBossWS, is it 100% compatible with my current JAX-RPC & JAX-WS web services running in their current AS? No changes required, just a drop in replacement? | No, neither CXF nor Metro support JAX-RPC. You can expect JAX-WS functionality that is covered by the jbossws framework testsuite (except documented errata in the release notes) to work. Also please note, that only jbossws-native is verified against the TCK. This is also the the only stack that is officially supported for customers. What we are introducing here is a community release only that is not available in any of the platforms. A switch to either CXF or Metro as our default platform stack is possible in the future, but will require more work not only from a tech perspective. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120177#4120177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120177

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: TimeoutException printing stacktraces of threads holding

by galder.zamarreno＠jboss.com

FYI, I have created a thread in Clustering forum to continue this discussion, see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=127721 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120176#4120176 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120176

18 years, 2 months

1
0
0 / 0

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

by ataylor

I'm fixing the tests now, I'll let you know when I'm done View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120175#4120175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120175

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Handling of 'deployments taking ~1 minute' scenario

by galder.zamarreno＠jboss.com

Quite often, users/customers encounter the ~1 min deployments scenario that. A node that has this slow startup can in theory be considered a working node with the caveat that maybe some nodes don't have DRM information for EJB proxies for example. However, I'm yet to see a customer who was happy to carry on with such a slow node. IOW, a customer who considered a node with these symptoms to be healthy. I covered debugging such scenario in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=127721 thread, but should we react to this scenario in a different way? Should we maybe evict the nodes failing to respond in time from the cluster? It might be a case that they're just slow, but if you kicked them out from the cluster, the next deployments would (potentially) work fine. Currently, we're only logging ignored missing responses as TRACE. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120174#4120174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120174

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Thread dumps generated by triggers/events?

by galder.zamarreno＠jboss.com

A while back, I started a thread about generating thread dumps if a Cache TimeoutException occurred (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123989). Another situation that comes to my mind would be when deployments take ~1 min, which are the result of a DRM.add cluster sync call hanging or just been slow. In both situations, getting a local or remote thread dump at the right point is key to find out what it's going on. Currently, we're relying on users providing such thread dumps and if they get the timing wrong, which can easily happen, it can get quite frustrating cos they'd have to retry...etc. Maybe this is something a monitoring tool could do? I.e. generate thread dumps in all nodes in the cluster upon certain circumstances/triggers/events? This is certainly a cross cutting concern not clustering specifically related, but it's key for Clustering in general, hence why I opened the thread here. If there's a different forum where this should be raised, please let me know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120170#4120170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120170

18 years, 2 months

1
0
0 / 0

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

by scott.stark＠jboss.org

The messaging-service.xml is what works for me in jbossas with the Branch_Stable code. I'm still trying to get the messaging tests running to validate changes locally. Is there a subset of tests I can run using hsqldb rather than having to setup mysql? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120166#4120166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120166

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

Crap. I see the following didn't make it into the interface: | /** | * Called by the HASingleton to set the name with which the singleton | * service is registered with the HAPartition. | */ | public void setServiceName(String serviceName); | | public String getServiceName(); | Those need to be there, otherwise an impl has no idea how to interact with the DRM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120158#4120158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120158

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

"galder.zamarreno(a)jboss.com" wrote : | 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. OK, makes sense to me. anonymous wrote : 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. | Those are needed. A design goal here is to make it possible for a custom policy impl to base its decision on factors beyond the simple topology info: 1) Can even call into cluster, for example to have some sort of vote. Need HAPartition. 2) Can use some arbitrary info from the singleton service itself. My expectation here is any custom impl will be based off the base class, so we're handling the trivial stuff of storing the partition and singleton service refs. And if someone makes there own impl not using the base class and can't get that part right, well .... Another thing to be aware of: the arg passed to HASingletonSupport.partitionTopologyChanged is really List newReplicants, where the list elements are *not* instances of ClusterNode. They are whatever "replicant" was registered for the service (i.e. an invoker stub, or in this case probably a String). There needs to be a translation into List. Looks like the way to do this is via DRM.lookupReplicantsNodeNames(String). BTW, I downgraded this back to Major as the standard deploy-hasingleton in 4.2 is not using HASingletonElectionPolicy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120157#4120157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120157

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: AnnotationMetaDataDeployer queries isMetadataComplete on

by scott.stark＠jboss.org

Yes, apply it. The AnnotationMetaDataDeployer can't wait for the merge as its output is input into the merge. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120152#4120152 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120152

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