From galder.zamarreno at redhat.com  Wed Jun 10 03:51:39 2009
From: galder.zamarreno at redhat.com (Galder Zamarreno)
Date: Wed, 10 Jun 2009 09:51:39 +0200
Subject: [jbosscache-dev] Accessing Cache instances from AS5
Message-ID: <4A2F660B.3020700@redhat.com>

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


From galder.zamarreno at redhat.com  Wed Jun 10 10:31:50 2009
From: galder.zamarreno at redhat.com (Galder Zamarreno)
Date: Wed, 10 Jun 2009 16:31:50 +0200
Subject: [jbosscache-dev] Accessing Cache instances from AS5
In-Reply-To: <4A2F660B.3020700@redhat.com>
References: <4A2F660B.3020700@redhat.com>
Message-ID: <4A2FC3D6.5020609@redhat.com>



Galder Zamarreno wrote:
> </snip>
> 
> 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.

Fixed PojoCache docu and JBoss Cache docu:
https://jira.jboss.org/jira/browse/JBCACHE-1513
https://jira.jboss.org/jira/browse/PCACHE-83

-
Galder Zamarre?o
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat


From brian.stansberry at redhat.com  Wed Jun 10 13:21:40 2009
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 10 Jun 2009 12:21:40 -0500
Subject: [jbosscache-dev] Re: [jboss-cluster-dev] Accessing Cache instances
	from AS5
In-Reply-To: <4A2F660B.3020700@redhat.com>
References: <4A2F660B.3020700@redhat.com>
Message-ID: <4A2FEBA4.70902@redhat.com>

Galder Zamarreno wrote:
> 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.
> 

Couple methods, discussed in more detail at http://tinyurl.com/lq688t 
section 11.2

1) Use the CacheManager to create your cache; the CacheManager is 
available in JNDI at java:/CacheManager. See Section 11.2.1.

2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. Simplest 
way is to deploy it via a -service.xml. Section 5.4.2 of JBC 3.1 docs at 
http://tinyurl.com/m49qen has other methods.

> 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.
> 

Remoting proxies to pojos can also be created. JBAS-4456. See forum 
discussion at http://tinyurl.com/n3zbgr and a test case example 
deployment config at http://tinyurl.com/lyta4y. But, as discussed on 
that forum thread, the JNDI-registration part got separated out into a 
separate concern, meant to be handled via the @JndiBinding annotation. 
Sometime after that discussion, support for @JndiBinding got removed 
from the default/all configs.  It can be added back by including


    <lifecycle-configure xmlns="urn:jboss:aop-beans:1.0"
       name="JndiBindingAdvice"
 
class="org.jboss.aop.microcontainer.aspects.jndi.JndiLifecycleCallback"
       classes="@org.jboss.aop.microcontainer.aspects.jndi.JndiBinding"
       manager-bean="AspectManager"
       manager-property="aspectManager"/>

in a -jboss-beans.xml, but, well, that whole process is just too much to 
advise as some sort of standard way of accessing JBC. Particularly since 
a remote proxy to org.jboss.cache.Cache isn't really valid; it doesn't 
cover the Node interface.

> 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.
> 

Thanks for fixing that!

> Cheers,


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat


From galder.zamarreno at redhat.com  Tue Jun 16 08:26:14 2009
From: galder.zamarreno at redhat.com (Galder Zamarreno)
Date: Tue, 16 Jun 2009 14:26:14 +0200
Subject: [jbosscache-dev] Re: [jboss-cluster-dev] Accessing Cache instances
	from AS5
In-Reply-To: <4A2FEBA4.70902@redhat.com>
References: <4A2F660B.3020700@redhat.com> <4A2FEBA4.70902@redhat.com>
Message-ID: <4A378F66.8000306@redhat.com>

Brian,

Thanks very much for providing such detailed information and the revised 
version of the AS Clustering Guide. I'll make sure I have a read to the 
entire guide asap since it contains very important information that I 
was not aware of.

Also, this makes me think that the whole 5.2 and 5.3 sections in the JBC 
docu (http://is.gd/13oVC) should go away or simply refer/link to AS 
Clustering Guide, since AS Clustering knows how to do this best and the 
JBC docu, unless kept tightly in check, will always be outdated. Thoughts?

Cheers,

Brian Stansberry wrote:
> Galder Zamarreno wrote:
>> 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.
>>
> 
> Couple methods, discussed in more detail at http://tinyurl.com/lq688t 
> section 11.2
> 
> 1) Use the CacheManager to create your cache; the CacheManager is 
> available in JNDI at java:/CacheManager. See Section 11.2.1.
> 
> 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. Simplest 
> way is to deploy it via a -service.xml. Section 5.4.2 of JBC 3.1 docs at 
> http://tinyurl.com/m49qen has other methods.
> 
>> 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.
>>
> 
> Remoting proxies to pojos can also be created. JBAS-4456. See forum 
> discussion at http://tinyurl.com/n3zbgr and a test case example 
> deployment config at http://tinyurl.com/lyta4y. But, as discussed on 
> that forum thread, the JNDI-registration part got separated out into a 
> separate concern, meant to be handled via the @JndiBinding annotation. 
> Sometime after that discussion, support for @JndiBinding got removed 
> from the default/all configs.  It can be added back by including
> 
> 
>    <lifecycle-configure xmlns="urn:jboss:aop-beans:1.0"
>       name="JndiBindingAdvice"
> 
> class="org.jboss.aop.microcontainer.aspects.jndi.JndiLifecycleCallback"
>       classes="@org.jboss.aop.microcontainer.aspects.jndi.JndiBinding"
>       manager-bean="AspectManager"
>       manager-property="aspectManager"/>
> 
> in a -jboss-beans.xml, but, well, that whole process is just too much to 
> advise as some sort of standard way of accessing JBC. Particularly since 
> a remote proxy to org.jboss.cache.Cache isn't really valid; it doesn't 
> cover the Node interface.
> 
>> 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.
>>
> 
> Thanks for fixing that!
> 
>> Cheers,
> 
> 

-- 
Galder Zamarre?o
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat


From galder.zamarreno at redhat.com  Tue Jun 16 08:39:17 2009
From: galder.zamarreno at redhat.com (Galder Zamarreno)
Date: Tue, 16 Jun 2009 14:39:17 +0200
Subject: [jbosscache-dev] Re: [jboss-cluster-dev] Accessing Cache instances
	from AS5
In-Reply-To: <4A378F66.8000306@redhat.com>
References: <4A2F660B.3020700@redhat.com> <4A2FEBA4.70902@redhat.com>
	<4A378F66.8000306@redhat.com>
Message-ID: <4A379275.6090408@redhat.com>

Galder Zamarreno wrote:
> Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>> 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.
>>>
>>
>> Couple methods, discussed in more detail at http://tinyurl.com/lq688t 
>> section 11.2
>>
>> 1) Use the CacheManager to create your cache; the CacheManager is 
>> available in JNDI at java:/CacheManager. See Section 11.2.1.
>>
>> 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. Simplest 
>> way is to deploy it via a -service.xml. Section 5.4.2 of JBC 3.1 docs 
>> at http://tinyurl.com/m49qen has other methods.

One thing to note here is that if using CacheJmxWrapperMBean is still 
valid, then we need to clarify whether it's really deprecated or not. 
The JBC code indicates is deprecated indicating that 
JmxRegistrationManager should be used but the latter only offers a way 
to register, it doesn't offer an alternative to get access to it via 
JMX. Mircea, thoughts?

Cheers,
-- 
Galder Zamarre?o
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat


From brian.stansberry at redhat.com  Tue Jun 16 10:24:03 2009
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 16 Jun 2009 09:24:03 -0500
Subject: [jbosscache-dev] Re: [jboss-cluster-dev] Accessing Cache instances
	from AS5
In-Reply-To: <4A378F66.8000306@redhat.com>
References: <4A2F660B.3020700@redhat.com> <4A2FEBA4.70902@redhat.com>
	<4A378F66.8000306@redhat.com>
Message-ID: <4A37AB03.5030907@redhat.com>

Agreed that maintaining AS integration docs in the JBC docs will lead to 
errors. Not that the AS docs aren't woefully out of date. :( But that 
will be fixed by end of month and thereafter <determination>they won't 
be badly out of date again as long as I'm involved.</determination>

I think AS integration notes in JBC/Infinispan should largely limit 
themselves to notes on any config changes that JBC/Infinispan made since 
the last AS release; i.e. stuff the AS docs couldn't cover.

Galder Zamarreno wrote:
> Brian,
> 
> Thanks very much for providing such detailed information and the revised 
> version of the AS Clustering Guide. I'll make sure I have a read to the 
> entire guide asap since it contains very important information that I 
> was not aware of.
> 
> Also, this makes me think that the whole 5.2 and 5.3 sections in the JBC 
> docu (http://is.gd/13oVC) should go away or simply refer/link to AS 
> Clustering Guide, since AS Clustering knows how to do this best and the 
> JBC docu, unless kept tightly in check, will always be outdated. Thoughts?
> 
> Cheers,
> 
> Brian Stansberry wrote:
>> Galder Zamarreno wrote:
>>> 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.
>>>
>>
>> Couple methods, discussed in more detail at http://tinyurl.com/lq688t 
>> section 11.2
>>
>> 1) Use the CacheManager to create your cache; the CacheManager is 
>> available in JNDI at java:/CacheManager. See Section 11.2.1.
>>
>> 2) Use CacheJmxWrapperMBean and it's "cache" mbean attribute. Simplest 
>> way is to deploy it via a -service.xml. Section 5.4.2 of JBC 3.1 docs 
>> at http://tinyurl.com/m49qen has other methods.
>>
>>> 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.
>>>
>>
>> Remoting proxies to pojos can also be created. JBAS-4456. See forum 
>> discussion at http://tinyurl.com/n3zbgr and a test case example 
>> deployment config at http://tinyurl.com/lyta4y. But, as discussed on 
>> that forum thread, the JNDI-registration part got separated out into a 
>> separate concern, meant to be handled via the @JndiBinding annotation. 
>> Sometime after that discussion, support for @JndiBinding got removed 
>> from the default/all configs.  It can be added back by including
>>
>>
>>    <lifecycle-configure xmlns="urn:jboss:aop-beans:1.0"
>>       name="JndiBindingAdvice"
>>
>> class="org.jboss.aop.microcontainer.aspects.jndi.JndiLifecycleCallback"
>>       classes="@org.jboss.aop.microcontainer.aspects.jndi.JndiBinding"
>>       manager-bean="AspectManager"
>>       manager-property="aspectManager"/>
>>
>> in a -jboss-beans.xml, but, well, that whole process is just too much 
>> to advise as some sort of standard way of accessing JBC. Particularly 
>> since a remote proxy to org.jboss.cache.Cache isn't really valid; it 
>> doesn't cover the Node interface.
>>
>>> 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.
>>>
>>
>> Thanks for fixing that!
>>
>>> Cheers,
>>
>>
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat


From galder.zamarreno at redhat.com  Wed Jun 24 11:32:39 2009
From: galder.zamarreno at redhat.com (Galder Zamarreno)
Date: Wed, 24 Jun 2009 17:32:39 +0200
Subject: [jbosscache-dev] Fixing MVCC(RC) + UnversionedNode for PCACHE-82
Message-ID: <4A424717.9000300@redhat.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttachDetachTest.java
Type: text/x-java
Size: 4568 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090624/bb857f4f/attachment.bin