o.j.c.s.StateTransferUnderLoadTest and JBCACHE-315
by Manik Surtani
I'm marking the above test as a known failure in build.xml (in HEAD)
so it is excluded from cruise control runs. This actually touches
more than one JIRA task, but I presume JBCACHE-315 is the main one?
Can someone confirm this - Vlad/Brian?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 11 months
Cache.getRegion() implementation
by Manik Surtani
Hi,
I see this in HEAD, in TreeCacheProxyImpl.getRegion():
for(int i=0; i < fqn.size(); i++)
{
Fqn f = fqn.getFqnChild(i);
if (treeCache.regionsRegistry.containsKey(f))
{
// first match is returned
return treeCache.regionsRegistry.get(f);
}
}
What is the purpose of this? If someone sets a region at Fqn.ROOT,
no other regions will be recognised or created. Is this the expected
behaviour?
Do you perhaps mean to start with the leaf, and if a region exists,
return it, if createIfAbsent is true, create it, else look higher up?
I.e.,
// first try and see if a region specific to the Fqn exists
if (treeCache.regionsRegistry.containsKey(fqn) return
treeCache.regionsRegistry.get(fqn);
// else attempt to create one
if (createIfAbsent)
{
Region r = new RegionImpl(treeCache, fqn);
treeCache.regionsRegistry.put(fqn, r);
return r;
}
// else look at parents, direct parents first.
Region r = null;
Fqn nextFqn = fqn;
while (r == null)
{
Fqn nextFqn = nextFqn.getParent();
r = treeCache.regionsRegistry.get(nextFqn);
if (nextFqn.isRoot()) break;
}
return r;
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 11 months
Reinstating CruiseControl for the 1.4.x branch
by Manik Surtani
Hi,
Some while back we had parallel cruise control runs for JBoss Cache:
on HEAD as well as on Branch_JBossCache_1_4_0. Could we pls
reinstate the latter, since there is a fair bit of work going on on
the 1.4.x branch, and we may release a 1.4.0.SP2 (or 1.4.1) at some
point.
Thanks,
Manik
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 11 months
FW: [JBoss JIRA] Created: (JBAS-3753) HAParititonImpl implements org.jgroups.ChannelListener
by Brian Stansberry
Hi,
The below issue pertains to JBC as well. Propagation of awareness of
shunning to user code may be less of an issue, but internal awareness is
important.
Brian Stansberry (JIRA) wrote:
> HAParititonImpl implements org.jgroups.ChannelListener
> ------------------------------------------------------
>
> Key: JBAS-3753
> URL: http://jira.jboss.com/jira/browse/JBAS-3753
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public (Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-5.0.1.CR1
>
>
> Currently if a JChannel is shunned and disconnects, higher level
> services are unaware of this and can't take any remedial action.
>
> We need to do something like implement ChannelListener so an
> HAPartition is aware when the events on the underlying channel occur.
> Then devise a scheme to propagate some of the events to user code.
> Preferably this will follow as much as possible the existing
> notification scheme; i.e. pass a new view to HAMembershipListener
> impls that doesn't include the current node.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 11 months
Re: Anycast
by Manik Surtani
Not the way the RPCDispatcher in JGroups works. I always pass in a
List of buddies, and usually this list would have 1 element (if
n=1). Either way, even if n=3 in a 500 node cluster the multicast is
inefficient.
(moving this to the JBC dev list)
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 5 Oct 2006, at 11:58, Ben Wang wrote:
> I thought for BR, we do unicast now when there is only one buddy
> (the default) and switch to multicast where is more than one?
>
> From: Bela Ban
> Sent: Thursday, October 05, 2006 2:53 PM
> To: Ben Wang; Brian Stansberry; Manik Surtani; Vladimir Blagojevic;
> Galder Zamarreno
> Subject: Anycast
>
> FYI,
>
> currently, buddy replication generates the *same* amount of traffic
> as multicasting to everyone. I created a JIRA issue, anycast, which
> when implemented will allow for sending of messages to a subset of
> the membership: http://jira.jboss.com/jira/browse/JGRP-338
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
18 years, 12 months
RE: [jbosscache-dev] RegionManager
by Ben Wang
Regarding Cache.getRegion(fqn) API, I also need to have an API that do like Cache.findRegion(fqn) that returns null if absent. So I am thinking either:
1. Create a new api, findRegion(fqn), or
2. modify the getRegion(fqn) to getRegion(fqn, createIfAbsent)
What one do you prefer?
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Ben Wang
Sent: Thursday, October 05, 2006 12:15 PM
To: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] RegionManager
Currently it will create another new region under the children fqn.
-----Original Message-----
From: Brian Stansberry
Sent: Thursday, October 05, 2006 11:33 AM
To: Ben Wang; jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] RegionManager
Sounds very logical. What does it do now?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Looks like Cache.getRegion(Fqn fqn) is the one that is most convenient
> to use (since activate region should not be in the responsibility of
> CacheSPI). But I am thinking to refine the contract of getRegion(Fqn
> fqn) such that if I have previously defined a parent region, say,
> "/person". Then doing a call
> getRegion("/person/joe") should still return the parent region
> associated with "/person". I think this is the logical. What do people
> think?
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Ben Wang
> Sent: Thursday, October 05, 2006 12:49 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] RegionManager
>
> Manik,
>
> Currently, we have Cache.getRegion and also
> CacheSPI.getEvictionRegionManager and CacheSPI.getRegionManager APIs.
> It seems that these two are a bit redundant in that one can also
> create a region from CacheSPI call. So what is the intention here?
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 12 months
RE: [jbosscache-dev] RegionManager
by Ben Wang
Currently it will create another new region under the children fqn.
-----Original Message-----
From: Brian Stansberry
Sent: Thursday, October 05, 2006 11:33 AM
To: Ben Wang; jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] RegionManager
Sounds very logical. What does it do now?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Looks like Cache.getRegion(Fqn fqn) is the one that is most convenient
> to use (since activate region should not be in the responsibility of
> CacheSPI). But I am thinking to refine the contract of getRegion(Fqn
> fqn) such that if I have previously defined a parent region, say,
> "/person". Then doing a call
> getRegion("/person/joe") should still return the parent region
> associated with "/person". I think this is the logical. What do people
> think?
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Ben Wang
> Sent: Thursday, October 05, 2006 12:49 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] RegionManager
>
> Manik,
>
> Currently, we have Cache.getRegion and also
> CacheSPI.getEvictionRegionManager and CacheSPI.getRegionManager APIs.
> It seems that these two are a bit redundant in that one can also
> create a region from CacheSPI call. So what is the intention here?
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 12 months
RE: [jbosscache-dev] RegionManager
by Brian Stansberry
Sounds very logical. What does it do now?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Looks like Cache.getRegion(Fqn fqn) is the one that is most
> convenient to use (since activate region should not be in the
> responsibility of CacheSPI). But I am thinking to refine the
> contract of getRegion(Fqn fqn) such that if I have previously
> defined a parent region, say, "/person". Then doing a call
> getRegion("/person/joe") should still return the parent
> region associated with "/person". I think this is the
> logical. What do people think?
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Ben Wang
> Sent: Thursday, October 05, 2006 12:49 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] RegionManager
>
> Manik,
>
> Currently, we have Cache.getRegion and also
> CacheSPI.getEvictionRegionManager and
> CacheSPI.getRegionManager APIs. It seems that these two are a
> bit redundant in that one can also create a region from
> CacheSPI call. So what is the intention here?
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 12 months
RE: [jbosscache-dev] RegionManager
by Ben Wang
Looks like Cache.getRegion(Fqn fqn) is the one that is most convenient to use (since activate region should not be in the responsibility of CacheSPI). But I am thinking to refine the contract of getRegion(Fqn fqn) such that if I have previously defined a parent region, say, "/person". Then doing a call getRegion("/person/joe") should still return the parent region associated with "/person". I think this is the logical. What do people think?
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Ben Wang
Sent: Thursday, October 05, 2006 12:49 AM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] RegionManager
Manik,
Currently, we have Cache.getRegion and also CacheSPI.getEvictionRegionManager and CacheSPI.getRegionManager APIs. It seems that these two are a bit redundant in that one can also create a region from CacheSPI call. So what is the intention here?
Thanks,
-Ben
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 12 months