Accessing Cache instances from AS5
by Galder Zamarreno
Hi,
Having looked at this forum post thread
(http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235313#4235313),
I wanted to check, specially with Brian, what's the preferred method in
AS5 to get access to a local cache.
First of all, anything bound to JNDI needs to be Serializable.
http://www.jboss.org/community/wiki/JMXMBeanRemoteProxy wiki explains
how to bind a proxy to an MBean into JNDI and retrieve it remotely.
Don't think this is what the user wants though. It looks as if he only
wants to access it from diff apps.
Traditionally, there was always the JMX method to retrieve a local Cache
instance (see http://is.gd/WOmk) but this section has dissapeared from
the latest JBC 3.1 documentation in http://is.gd/WOsH.
I know that CacheJmxWrapperMBean and CacheJmxWrapper have been
deprecated and instead org.jboss.cache.jmx.JmxRegistrationManager is now
in place but it's unclear from the code what's the alternative. One that
I can think of is MC bean injection but that assumes your app is build
around MC beans which could or not happen.
Finally, one thing to note to everyone, if you simply name your MC bean
with -beans.xml, it won't deploy it!! Thanks to Emanuel who helped me
figure out why a cache instance wouldn't deploy. Instead, it should be
named -jboss-beans.xml. I'll create a JIRA to fix this.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years, 5 months
- 3
- 7
Fixing MVCC(RC) + UnversionedNode for PCACHE-82
by Galder Zamarreno
Hi all,
Re: https://jira.jboss.org/jira/browse/PCACHE-82
Even though this is not urgent, it's a good exercise for me to get a
better understanding of MVCC and hence why I decided to finally tackle it.
I've been trying to figure out what exactly is the bug in this JIRA.
I've created a test case that reproduces the bug (attached). The issue
is clearly related to MVCC(ReadCommitted) and UnversionedNode instances
but I'm failing to understand what the fix exactly is.
Let me sum up what happens internally (note that a lot of the
information below is from logging statements I added):
1. Create a Person, Galder, and attach it under
/person/testDoubleAttachAndDetach
2. Create a Person, Asier, and attach it in the same fqn.
3. In the 2nd attachment, ReadCommittedNode.markForUpdate() backs up the
NodeReference for /person/testDoubleAttachAndDetach creates a copy of
the UnversionedNode representing underneath.
4. More importantly, because calling attach the 2nd time means detach
needs to happen before to remove the old value, so
MVCCNodeHelper.wrapNodesRecursivelyForRemoval() executes the addChild()
below:
// update child ref on parent to point to child as this is now a copy.
if (parentLockNeeded && (needToCopyNode || needToCopyParent)) {
if (parent == null) throw new NodeNotExistsException("Parent node " +
parentFqn + " does not exist!");
parent.getDelegationTarget().addChild(node.getDelegationTarget());
}
This leads to adding the UnversionedNode version of
testDoubleAttachAndDetach to /person node's children.
5. At the end 2nd attachment, ReadCommittedNode.updateNode() method
takes the backup (NodeReference) and the node (UnversionedNode) and
swaps them again but the parent's children, /person, is still pointing
to an UnversionedNode which leads to the ClassCastException that you see
when you execute the test.
I'm not sure what really should be happening here since I don't
understand the rationaly of that addChild() call. Should it be happening
at all in this case? Or maybe a corrective action of some sort needs to
be done somewhere?
Thanks for the help in advance!
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 5 months
- 2
- 1
- ← Newer
- 1
- Older →