RE: [jbosscache-dev] Releasing 1.4.1.GA
by Vladimir Blagojevic
Yes. I have to learn how to think about multiple things at once.
I fixed this in HEAD but not 1.4. Sorry about the confusion.
> The state transfer tests have been failing on
> jboss-cache-testsuite-140 since Tues. There are 2 eviction
> tests and they weren't cleaning up after themselves properly,
> so I believe live caches left over from the first were
> impacting the second. This has been fixed in 1.4.x and will
> be in HEAD if it's broken there.
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
17 years, 4 months
RE: [jbosscache-dev] Releasing 1.4.1.GA
by Brian Stansberry
Manik Surtani wrote:
> On 5 Jan 2007, at 16:02, Manik Surtani wrote:
>
>> On 5 Jan 2007, at 15:37, Brian Stansberry wrote:
>>
>>> At this point it's completely unclear what their issue is. I
>>> wouldn't hold up a release for it beyond one more day.
>>>
>>> Manik, perhaps you can have a look at
>>>
> o.j.c.statetransfer.VersionedTestBase.testEvictionAfterStateTransfer(
>>> ) and see if you think it adequately tests eviction following state
>>> transfer. It actually goes beyond that quite a bit now, and tests
>>> eviction in the presence of concurrent creation of new nodes.
>>
>> This is the only test failing in o.j.c.statetransfer on HEAD at the
>> moment. When was this test added?
>
> Pls ignore, this is irrelevant. It passes fine on 1.4.x.
>
> The test does seem to, as you suggest, test eviction of nodes created
> via state transfer.
>
The state transfer tests have been failing on jboss-cache-testsuite-140
since Tues. There are 2 eviction tests and they weren't cleaning up
after themselves properly, so I believe live caches left over from the
first were impacting the second. This has been fixed in 1.4.x and will
be in HEAD if it's broken there.
17 years, 4 months
RE: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
by Galder Zamarreno
Done for head and 1.4.x.... with comments :)
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 03 January 2007 17:19
To: Galder Zamarreno
Cc: Hany Mesha; jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
On 28 Dec 2006, at 14:29, Galder Zamarreno wrote:
> I managed to get it sorted passing lib.dir in build.xml as system
> property to the tests. In the test, I'm trying to create a CL
> without parent CL. I can only use jar files for this as the classes
> directory for the IDE could be different depending on the person.
> Alternatively, I guess I could maybe use javassist to generate
> something on the fly.
>
> The test did not work when the test was executed from a different
> directory to the JBC root one, for example for CC. By passing the
> lib dir as system property, I can check whether it's set.
>
> If set, use the system property, quite likely build.xml run. If not
> set, quite likely IDE run which allows lib dir to be hardcoded.
>
> It's a bit hacky, I admit, any better ideas?
As long as it works and is documented well enough in comments ... :-)
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 28 December 2006 13:23
> To: Manik Surtani; Hany Mesha
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
>
> I added this unit test. I'm working on the fix :)
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: 19 December 2006 11:32
> To: Hany Mesha
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
>
> Looking at
>
> http://cruisecontrol.jboss.com/cc/artifacts/jboss-cache-
> testsuite-140/20061219021805/results/index.html
>
> I only see one test failing
> (org.jboss.cache.marshall.RedeploymentEmulationTest) but I suspect
> this has to do with a bug in the test's setup and teardown, since
> when run on its own, it passes.
>
>
> --
> 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 19 Dec 2006, at 04:08, Hany Mesha wrote:
>
>> Hi all,
>>
>> I've run Clover against Branch_JBossCache_1_4_0 and the initial
>> generated report and statistics are posted on the wiki at
>> http://wiki.jboss.org/wiki/Wiki.jsp?
>> page=JBossCache14xCodeCoverageAnalysis
>>
>> We have an overall coverage of 89.6 % which is pretty good number
>> for
>> initial report considering that there are test cases failing. If
>> those
>> test cases get fixed, I'll be able to produce more accurate report
>> and
>> therefore I'll be able to identify areas that are not covered in the
>> test suite and write test cases to cover those in the next few days
>> before releasing 1.4.1 GA.
>>
>> Please let me know if you're working on fixing one or more test
>> case in
>> the 1.4 branch and when you think you'll check that fix in?
>>
>> Thanks,
>>
>> -Hany
>>
>>
>>
>> Hany M. Mesha
>> Sr. Software Engineer, Consultant
>> Novell Identity Management Engineering
>> Toronto, Canada
>> hmesha(a)novell.com
>> Mobile: 416-456-6945
>> skype: hanymesha
>>
>> Novell, Inc.
>> SUSE® Linux Enterprise 10
>> Your Linux is ready
>> http://www.novell.com/linux
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
RE: [jbosscache-dev] Releasing 1.4.1.GA
by Brian Stansberry
At this point it's completely unclear what their issue is. I wouldn't hold up a release for it beyond one more day.
Manik, perhaps you can have a look at o.j.c.statetransfer.VersionedTestBase.testEvictionAfterStateTransfer() and see if you think it adequately tests eviction following state transfer. It actually goes beyond that quite a bit now, and tests eviction in the presence of concurrent creation of new nodes.
The only other thing I can think of is a test of eviction in the presence of lock conflicts. Do we test that?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> The only potential issue remaining is this:
> https://na1.salesforce.com/50030000002Y9ZW
>
> After Brian's fix for
> http://jira.jboss.com/jira/browse/JBCACHE-913, we haven't
> still worked out whether the customer's facing a bug or not yet.
>
> Brian, what do you think?
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value
> http://www.redhat.com/promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik
> Surtani Sent: 05 January 2007 12:53
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Releasing 1.4.1.GA
>
>
> Guys,
>
> Is there anything else pending for 1.4.1.GA? I'd like to tag
> this for release if there is nothing else.
>
> Cheers,
> Manik
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 4 months
RE: [jbosscache-dev] Releasing 1.4.1.GA
by Brian Stansberry
Manik Surtani wrote:
> On 5 Jan 2007, at 15:37, Brian Stansberry wrote:
>
>> At this point it's completely unclear what their issue is. I wouldn't
>> hold up a release for it beyond one more day.
>>
>> Manik, perhaps you can have a look at
>> o.j.c.statetransfer.VersionedTestBase.testEvictionAfterStateTransfer
>> () and see if you think it adequately tests eviction following state
>> transfer. It actually goes beyond that quite a bit now, and tests
>> eviction in the presence of concurrent creation of new nodes.
>
> This is the only test failing in o.j.c.statetransfer on HEAD
> at the moment. When was this test added?
>
I must have broken it when I ported it. I'll fix it.
>>
>> The only other thing I can think of is a test of eviction in the
>> presence of lock conflicts. Do we test that?
>
> I don't see anything of the sort, probably something we should add.
> Ben, do you know if any of the existing algorithm/policy tests test
> this case indirectly, at least?
>
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> The only potential issue remaining is this:
>>> https://na1.salesforce.com/50030000002Y9ZW
>>>
>>> After Brian's fix for
>>> http://jira.jboss.com/jira/browse/JBCACHE-913, we haven't
>>> still worked out whether the customer's facing a bug or not yet.
>>>
>>> Brian, what do you think?
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value
>>> http://www.redhat.com/promo/vendor/
>>>
>>> -----Original Message-----
>>> From: jbosscache-dev-bounces(a)lists.jboss.org
>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik
>>> Surtani Sent: 05 January 2007 12:53
>>> To: jbosscache-dev(a)lists.jboss.org
>>> Subject: [jbosscache-dev] Releasing 1.4.1.GA
>>>
>>>
>>> Guys,
>>>
>>> Is there anything else pending for 1.4.1.GA? I'd like to tag
>>> this for release if there is nothing else.
>>>
>>> Cheers,
>>> Manik
17 years, 4 months
RE: [jbosscache-dev] API changes in Habanero
by Ben Wang
Got a typo in my previous email. What I meant was, "I really like the explicit [api] naming in this case". So I am with you here. :-)
For the tangent, re: get rid of synchronization on the data map, do we have any evidence on how much speed up we will gain?
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Friday, January 05, 2007 4:30 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] API changes in Habanero
On 5 Jan 2007, at 01:39, Ben Wang wrote:
> OK, so we are saying XXxDirect belongs in NodeSPI because they are
> used only for cache behavior customization? But I'd like the explict
> naming in this case. Previously, you always need to remember to set
> the option each time before the method call.
>
Not really for cache behaviour customisation at all, but for direct node access.
E.g., Node.get(Object key) could do 2 things:
1) pass a call up the interceptor stack, to make sure the node is locked, cache loaders are considered, etc etc, and then retrieve the value of some data in the node.
2) or it could ignore the interceptor stack and retrieve some data from the node's data map.
In JBC 1.x, (1) was never supported directly from a node. You had to go through TreeCache to do this. Node.get() always performed (2).
in 2.0.0.ALPHA1, both (1) and (2) were supported, depending on whether BypassInterceptorChain was set to true as an option. I explained earlier how this is ugly, cumbersome, and not performant (constant checking of a thread-local variable)
This is why for 2.0.0.ALPHA2, I split such methods into 2 separate ones. Node.get(Object key) performs (1) above. NodeSPI.getDirect (Object fqn) performs (2) above. This also nicely encapsulates direct access from the user API.
I'm not sure what you meant by explicit naming, I thought this is what I have achieved here. :-) Previously naming was ambiguous in that the method performed one of two things - (1) or (2) above - based on an option passed in. Really bad design to rely on a 'global' like that. :-)
> Another minor issue that I find in my unit test:
> java.lang.UnsupportedOperationException: Cannot directly retrieve
> children which aren't directly under the current node.
> at org.jboss.cache.UnversionedNode.getChildDirect
> (UnversionedNode.java:424)
>
> It seems now:
>
> NodeSPI node = cache.getRoot().getChildDirect(fqn);
> Only support the retrieval of immediate child. So if, say, I have "/
> a/b/c" fqn that I want to retrieve from getRoot(), what is my option
> then? I'd think to iterate through the Node tree to get a child node
> is quite tedious and inefficient.
>
Yes, I put this in since I was trying to emulate direct child access for the node in the xxxDirect() methods. But you are correct, I don't see why this has to be the case and I have changed it in CVS HEAD to not throw this exception and walk the tree internally.
I also need to update the javadocs on the xxxDirect() methods to state that the onus is on the caller to make sure appropriate locks are obtained, etc. as this call does not go through the interceptor chain. Given that the intent of these methods are for SPI use only, typically from within an interceptor, the user of the SPI would be aware of such constraints and be able to deal with it.
And as a tangent, I was thinking about checking on access for such direct methods and wanted everyone's ideas:
At the moment, xxxDirect() methods that access, for example, the child map or data map of a node are synchronized. Now this is overkill, but it enforces correctness. Since we assume that callers to the xxxDirect() methods obtain appropriate locks in all cases, is it safe to remove the synchronization, and instead add a lock- ownership check to such methods.
For example:
public Object getDirect(Object key)
{
if (!getLock().getReaderOwners().contains(Thread.currentThread()))
throw new CacheException("Current thread does not have a read lock on node " + fqn);
return data == null? null : data.get(key); }
This would pretty rightly encapsulate and enforce concurrent access rules on the nodes, even with direct access. And cheaper than synchronizing the direct access methods. What do you guys think?
Cheers,
Manik
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Thursday, January 04, 2007 10:47 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] API changes in Habanero
>
> Guys,
>
> Here are a few major refactorings I've done on HEAD (checked in
> already). Some of these are on the API level and do affect the way
> interceptors and other subsystems interact with the node structure,
> hence the email.
>
> * Got rid of the horrible BypassInterceptorChain malarky when
> interacting with nodes and you don't want calls up the interceptor
> chain
> * Used by interceptors themselves, as well as other internal
> subsystems including state transfer and the cache itself.
> * BypassInterceptorChain will still exist as an Option, as there are
> some valid use cases for this.
> * This option is now SOLELY handled by the
> InvocationContextInterceptor, which directs the call to the last
> interceptor in the chain if the option is present
> * Not handled internally in Node implementation methods anymore
> * Replaced with a bunch of XXXDirect() methods on NodeSPI for direct
> interaction/bypassing interceptor chains
> * E.g., Node.getChild(Fqn f) goes up the interceptor chain,
> NodeSPI.getChildDirect(Fqn f) operates directly on the node.
> * Benefits: much easier to read, understand and maintain, more
> performant.
>
> * Got rid of Node.getNodeSPI()
> * NodeSPI interface can now be easily obtained since all methods on
> NodeSPI which would otherwise return Node now return NodeSPI
> * Methods on Cache (such as getRoot()) which would return Node are
> overridden in CacheSPI to return NodeSPI.
> * Gives interceptors and the like access to NodeSPI without letting
> this interface escape to the user API.
> * There are still a very small handful of cases where direct casts
> are necessary, but this is very internalised (within UnversionedNode
> and WorkspaceNode, for example) and a bunch of unit tests (for closer
> inspection)
> * In general, NodeSPI is now much tighter and can only officially be
> obtained from another NodeSPI or a CacheSPI.
>
> * Got rid of NodeSPI.getRawData() - superfluous now that we have
> NodeSPI.getDataDirect()
>
> This stuff should give us a much more robust data model and user/ SPI
> interface for the nodes and caches.
>
> Please let me know what you think or if you have any issues/further
> suggestions.
>
> 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
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
RE: [jbosscache-dev] Releasing 1.4.1.GA
by Galder Zamarreno
The only potential issue remaining is this:
https://na1.salesforce.com/50030000002Y9ZW
After Brian's fix for http://jira.jboss.com/jira/browse/JBCACHE-913, we haven't still worked out whether the customer's facing a bug or not yet.
Brian, what do you think?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 05 January 2007 12:53
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Releasing 1.4.1.GA
Guys,
Is there anything else pending for 1.4.1.GA? I'd like to tag this
for release if there is nothing else.
Cheers,
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
Releasing 1.4.1.GA
by Manik Surtani
Guys,
Is there anything else pending for 1.4.1.GA? I'd like to tag this
for release if there is nothing else.
Cheers,
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
17 years, 4 months
RE: [jbosscache-dev] API changes in Habanero
by Ben Wang
OK, so we are saying XXxDirect belongs in NodeSPI because they are used only for cache behavior customization? But I'd like the explict naming in this case. Previously, you always need to remember to set the option each time before the method call.
Another minor issue that I find in my unit test:
java.lang.UnsupportedOperationException: Cannot directly retrieve children which aren't directly under the current node.
at org.jboss.cache.UnversionedNode.getChildDirect(UnversionedNode.java:424)
It seems now:
NodeSPI node = cache.getRoot().getChildDirect(fqn);
Only support the retrieval of immediate child. So if, say, I have "/a/b/c" fqn that I want to retrieve from getRoot(), what is my option then? I'd think to iterate through the Node tree to get a child node is quite tedious and inefficient.
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, January 04, 2007 10:47 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] API changes in Habanero
Guys,
Here are a few major refactorings I've done on HEAD (checked in already). Some of these are on the API level and do affect the way interceptors and other subsystems interact with the node structure, hence the email.
* Got rid of the horrible BypassInterceptorChain malarky when interacting with nodes and you don't want calls up the interceptor chain
* Used by interceptors themselves, as well as other internal subsystems including state transfer and the cache itself.
* BypassInterceptorChain will still exist as an Option, as there are some valid use cases for this.
* This option is now SOLELY handled by the InvocationContextInterceptor, which directs the call to the last interceptor in the chain if the option is present
* Not handled internally in Node implementation methods anymore
* Replaced with a bunch of XXXDirect() methods on NodeSPI for direct interaction/bypassing interceptor chains
* E.g., Node.getChild(Fqn f) goes up the interceptor chain, NodeSPI.getChildDirect(Fqn f) operates directly on the node.
* Benefits: much easier to read, understand and maintain, more performant.
* Got rid of Node.getNodeSPI()
* NodeSPI interface can now be easily obtained since all methods on NodeSPI which would otherwise return Node now return NodeSPI
* Methods on Cache (such as getRoot()) which would return Node are overridden in CacheSPI to return NodeSPI.
* Gives interceptors and the like access to NodeSPI without letting this interface escape to the user API.
* There are still a very small handful of cases where direct casts are necessary, but this is very internalised (within UnversionedNode and WorkspaceNode, for example) and a bunch of unit tests (for closer
inspection)
* In general, NodeSPI is now much tighter and can only officially be obtained from another NodeSPI or a CacheSPI.
* Got rid of NodeSPI.getRawData() - superfluous now that we have
NodeSPI.getDataDirect()
This stuff should give us a much more robust data model and user/SPI interface for the nodes and caches.
Please let me know what you think or if you have any issues/further suggestions.
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
RE: [jbosscache-dev] JMX interfaces for Habanero
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Guys,
>
> (Particularly Brian)
>
> Are we happy with the current JMX interfaces on Habanero? Is
> there any more work to be done on this, or can I close JBCACHE-768?
>
The JMX classes still need to be cleaned up. Won't happen this week
though.
As for the interfaces, is all the stuff from the discussion from
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971235#3971235
implemented?
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 4 months
