RE: [jbosscache-dev] Region.markNodeCurrentlyInUse
by Brian Stansberry
Manik Surtani wrote:
> Sorry I've been out of this for a while (kind of shelved
> 2.0.0 issues so I could clear the stack of stuff sitting on top
> 1.3.0.SP4 and then
> 1.4.1)
>
> On 15 Nov 2006, at 14:51, Brian Stansberry wrote:
>
>> The purpose of this method is to allow an application to signal the
>> eviction policy to not evict a particular node who's data it's using.
>> Needed in situations where the app doesn't hold a lock on the node
>> *and* where evicting the node will cause a problem.
>>
>> AFAICT, this use case is really just for EJB3 SFSBs, where the
>> problem is that evicting an "in-use" node forces the container to
>> call prePassivate() on the in-use EJB. This is done from a
>> CacheListener.
>>
>> This is all a bit funky. Adding methods to the API to deal with a
>> very specific use case. It also has a small race condition, which I
>> won't get into here.
>>
>> Here's a different (but still funky) approach:
>>
>> Add a new exception class o.j.c.eviction.NodeInUseException extends
>> RuntimeException.
>>
>> The application implements CacheListener. When it gets a
>> nodePassivated(pre=true) event, if it doesn't want the passivation,
>> it throws the NodeInUseException. This will abort the eviction and
>> propagate back to the eviction policy. Eviction policies are already
>> written such that they catch all exceptions, and then throw the node
>> into a retry queue (see
> BaseEvictionAlgorithm.evictCacheNode()). If we
>> wanted to get fancy, we could specifically catch NodeInUseException
>> and decide from there whether to add it to the retry queue.
>>
>> I don't think we should try to change this this week; more of a
>> short term future thing.
>>
>> Thoughts?
>
> Your second (and still funky) approach does seem a lot
> cleaner than hacking in stuff into the API for a very
> specific use case. So certainly my preferred option. But
> from a performance standpoint, is this really an
> "exceptional" circumstance?
>
For a man with no rhythm I come up with a lot of funky stuff. ;)
Should be an exceptional circumstance. The bean would have to be in use
longer than the configured timeToLiveSeconds. That can be configured per
bean class via an annotation and defaults to 300 seconds. IMO an EJB
configured to passivate in less time than it's expected to be used in a
tx is a misconfigured EJB.
There would probably be a small performance pickup by getting rid of the
mark/unmarkNodeInUse calls every time an SFSB is pulled from the
cache/returned to the cache.
One thing to think more about is whether the LRUPolicy should queue the
node for eviction retry if it catches this exception, or just let it go
and wait for the node to be evicted again via the regular path.
Queueing for retry increases the chances that the node will still be in
use a few seconds later when the eviction runs again, causing another
exception would be thrown. Need to check if not retyring risks leaking
nodes.
19 years
Region.markNodeCurrentlyInUse
by Brian Stansberry
The purpose of this method is to allow an application to signal the
eviction policy to not evict a particular node who's data it's using.
Needed in situations where the app doesn't hold a lock on the node *and*
where evicting the node will cause a problem.
AFAICT, this use case is really just for EJB3 SFSBs, where the problem
is that evicting an "in-use" node forces the container to call
prePassivate() on the in-use EJB. This is done from a CacheListener.
This is all a bit funky. Adding methods to the API to deal with a very
specific use case. It also has a small race condition, which I won't
get into here.
Here's a different (but still funky) approach:
Add a new exception class o.j.c.eviction.NodeInUseException extends
RuntimeException.
The application implements CacheListener. When it gets a
nodePassivated(pre=true) event, if it doesn't want the passivation, it
throws the NodeInUseException. This will abort the eviction and
propagate back to the eviction policy. Eviction policies are already
written such that they catch all exceptions, and then throw the node
into a retry queue (see BaseEvictionAlgorithm.evictCacheNode()). If we
wanted to get fancy, we could specifically catch NodeInUseException and
decide from there whether to add it to the retry queue.
I don't think we should try to change this this week; more of a short
term future thing.
Thoughts?
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
19 years
RE: [jbosscache-dev] RE: JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
This change is made on 1.4 and HEAD.
When I looked at it, the effiency gain from using a Set vs a List only
exists with the locks collection. So that's the only one I changed to
LinkedHashSet. The methods that add things to the other list fields
(e.g. modifications) don't do a contains() check to see if what they are
adding is already there, so they don't have the inefficiency. Presumably
this means that with normal behavior the same object wouldn't get added
twice to these lists. A cursory check showed that to be the case, and
if it weren't I'd expect we'd have noticeable bugs. So, I decided not to
change to other fields to LinkedHashSet -- didn't want to introduce
issues by making a change. At least not in 1.4.
I ran the testsuite and saw no regressions vs cc. But, there are a lot
of failures now on cc, so I'm going to wait to close JBCACHE-874 until
we get some cleaner test runs.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Manik Surtani wrote:
>> On 5 Dec 2006, at 19:29, Brian Stansberry wrote:
>>
>>> Manik Surtani wrote:
>>>> Brian Stansberry wrote:
>>>>> It's not a big deal if JBCACHE-874 doesn't go in 1.4.1.CR1, but it
>>>>> would be nice to get it in so it's out in the wild longer before
>>>>> the GA.
>>>>
>>>> Sorry yes, forgot about this.
>>>>
>>>
>>> If you're delaying 1.4.1.CR1 for this, let me know, because at this
>>> point I was deferring it a bit pending anything that comes out of
>>> this thread.
>>
>> What would you like me to do? When do you think you could have 874
>> in?
>>
>
> Probably by tomorrow. If there's going to be a CR2 I'd prefer
> you don't delay CR1 for this. Getting things out in the wild
> is good, the benefit of having this out in CR1 is outweighed
> by the benefit of getting everything else in CR1 out in the
> wild sooner.
>
>>>
>>>>>
>>>>> 1) A bunch of the LinkedList fields in TransactionEntry are
>>>>> protected. Changing them to LinkedHashSet therefore technically
>>>>> changes the API. This is an internal class, so I don't think
>>>>> that's an issue. Any objections?
>>>>
>>>> I'm ok with this, I don't think it will break the
>>>> OptimisticTransactionEntry subclass. In fact, is there any reason
>>>> why this needs to be protected? Could we make do with stronger
>>>> access protection than protected?
>>>>
>>>
>>> I don't see any reason why not; this is an internal class. I much
>>> prefer private fields; hate protected 'cause it's never clear to me
>>> if the class designer had a strong reason to expose them or just did
>>> it "in case some subclass wants it some day". IMHO a protected
>>> getter/setter with a private field is a much better indication of
>>> design intent and allows clean subsequent addition of things like
>>> lazy initialization.
>>
>> +1. And like I said, if we can make do with package-level access for
>> the getter/setter and private for the field, I'd go with that if it
>> makes sense.
>>
>
> I'll check; we may not even need the getters/setters for this
> particular case. I don't think the subclass uses any of the
> protected fields. And if not, I don't think there is any real
> "design intent" to expose them.
> If later on, we find a real need to expose them, then we add them.
>
>>>
>>>>>
>>>>> 2) A number of TransactionEntry methods return List and currently
>>>>> hand out a ref to the internal data structure. The caller of
>>>>> these methods logically expects a List so I think the API should
>>>>> remain the same. So, that implies the methods would do something
>>>>> like "return new ArrayList(internalSet);"
>>>>>
>>>>
>>>> Hmm, I guess so. Perhaps in 2.0.0, change this to return a
>>>> Collection?
>>>>
>>>
>>> Maybe. Depends on whether callers are relying on an expected
>>> ordering. I had a quick look at these methods yesterday. At least
>>> one is never invoked and thus can be dropped. For another, at least
>>> in some cases, Set semantics are fine, so a possibility for 1.4.1 is
>>> an added method that exposes the internal Set.
>>
>> Ok, I'm happy with this. Like you said, this *is* an internal class
>> anyway.
>>
>
> Yes. And if there is a path whereby outside code can access
> this class (I think there is), adding methods doesn't break
> any compatibility.
>
>>>
>>> Another possibility for 2.0.0 is to return an Iterator over the
>>> internal field, which would give the same ordering as a List with no
>>> extra effort. I expect all the callers already end up iterating
>>> over the List anyway.
>>
>> Is this the case? What about calling contains() on the List? I
>> thought I saw this somewhere ...
>
> You did, but the contains() call is done internally to
> TransactionEntry whenever any of the add methods are called
> -- in order to ensure Set semantics on the internal lists.
> Getting rid of this inefficiency is the primary benefit of
> JBCACHE-874.
>
> - Brian
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years
JBoss Cache cruise control not run?
by Manik Surtani
Guys,
For some reason the last time the test suite (both on HEAD and on the
1.4.0 branch) was run was Friday, the 8th of Dec. Has CC got stuck?
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
19 years
Latest CacheLoaderInterceptor changes
by Vladimir Blagojevic
Hey Elias,
Latest HEAD changes of CacheLoaderInterceptor cause some of state
transfer tests to blow up with Throwable although not recorded on CC.
The specific change was the last change in HEAD and was related to
method createTempNode.
In createTempNode if I remove code line n.getNodeSPI().setDataLoaded()
this problem goes away. setDataLoaded is already taken care of in
createNodes() called from createTempNode. BTW setDataLoaded in NodeImpl
is very confusing. It does have TODO marker "remove this" :) Would you
please give this issue some thought?
Regards,
Vladimir
19 years
RE: [jbosscache-dev] Notifying TxInterceptor of Jgroups BLOCK event
by Brian Stansberry
To me B sounds better, assuming no one has "Any other idea". As soon as
you implement and test A, we'll think of some reason why some other
interceptor needs to know about the block call!
Re: the local option, the ReplicationInterceptor already ignores methods
it's not specifically designed to handle.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hi,
>
> As a part of JBCACHE-315 implementation we have to notify
> TXInterceptor that Jgroups BLOCK event arrived. I could think of two
> solutions:
>
> A) Find TxInterceptor in interceptor list and invoke
> TxInterceptor.block() directly
> B) Pass block notification as a method down the interceptor
> chain and implement logic in TxInterceptor
>
> For B) do we have to set option override that method is local
> so method call does not get replicated?
>
> Which approach is preferred? Any other ideas?
>
> Regards,
> Vladimir
>
> _______________________________________________
> 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
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
19 years
RE: [jbosscache-dev] Region activation of a root node
by Brian Stansberry
Yes. It allows registration of a classloader for use with the entire
cache.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> I noticed that
> o.j.c.statetransfer.VersionedTestBase#testLoadEntireStateAfter
> Start does region activation on a root node. Region
> activation triggers partial state transfer but since we are
> activating root node partial state transfer mechanism rejects this
> requests.
>
> Do we allow region activation on a root node (i.e
> cache.getRegion(Fqn.ROOT, true).activate())?
>
>
> _______________________________________________
> 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
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
19 years
Region activation of a root node
by Vladimir Blagojevic
I noticed that
o.j.c.statetransfer.VersionedTestBase#testLoadEntireStateAfterStart does
region activation on a root node. Region activation triggers partial
state transfer but since we are activating root node partial state
transfer mechanism rejects this requests.
Do we allow region activation on a root node (i.e
cache.getRegion(Fqn.ROOT, true).activate())?
19 years
Notifying TxInterceptor of Jgroups BLOCK event
by Vladimir Blagojevic
Hi,
As a part of JBCACHE-315 implementation we have to notify TXInterceptor
that Jgroups BLOCK event arrived. I could think of two solutions:
A) Find TxInterceptor in interceptor list and invoke
TxInterceptor.block() directly
B) Pass block notification as a method down the interceptor chain and
implement logic in TxInterceptor
For B) do we have to set option override that method is local so method
call does not get replicated?
Which approach is preferred? Any other ideas?
Regards,
Vladimir
19 years
BuddyPool "exclusive"
by Brian Stansberry
Was just editing some docs and realized our standard example use case
for buddy pools is bogus. ;)
The example is to use buddyPoolName to group servers so that a server
only chooses as a buddy a server on a separate rack with separate power
supply etc.
If you think about it, this only makes sense if each buddy pool only has
2 servers, one on each rack. As soon as you have 3 servers in a pool,
the odds are only 50% that a server will pick one from the other rack as
its buddy.
Some kind of "exclusive" flag could help here -- i.e., pick my buddy
from among those where "this.buddyPoolName.equals(other.buddyPoolName)
== false". So then those on rack #1 have buddyPoolName "rack1" and
those on rack #2 have buddyPoolName "rack2" and all buddies are on the
other rack.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years
