RE: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
by Galder Zamarreno
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?
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 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@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
18 years
VAM in JDBCCacheLoader : performance numbers and analysis
by Galder Zamarreno
Hi,
I've been doing some performance tests for JDBCCacheLoader with both normal Java Serialization and VersionAwareMarshaller, using the existing JDBCCacheLoaderPerfTest.
The results I got back were quite suprising. Executing a test consisting of 10 threads (each thread interacts with a single node) and each thread adds 100 key/value pairs to their node. Tests showed that normal serialization was something like 15 times faster than VAM when it came to writes. For reads, normal serialization was still 4 times faster. We're talking about String/String key value pairs here.
Looking a bit deeper with the profiler, I have seen that TreeCacheMarshaller200 takes ages marshalling a map containing string key/value pairs. Is this expected? We're adding quite a few things to a simple String/String map, such as versioning and reference information. Compared to standard writeObject in HashMap, TreeCacheMarshaller200 spends quite a bit of time mantaining/updating a reference map.
In this case, for a single put, each key and value values are different (key0/value0 key1/value1 key2/value2...), maintaining references becomes an extra overhead as the reference maps are created for each request to marshall the original map. However, I can see the point why it was done (avoid extra serialization and reduce the amount of data in the wire).
I had a quick thought about caching reference data so that it survived several requests to marshal data, but it's probably a bad idea as this cache would become a contention for concurrent marshalling and increase the memory requirements. Has anyone been this route before? I think it might only produce positive results in such specific test as this.
I tried JBoss serialization and the results were even worse. What type of Objects is JB serialization recommended for? Is it user defined ones?
I have attached JProfiler files from all three tests and also a CVS diff in case anyone wants to have a quick glance. Note that even though there's 1000 calls to marshallMap, as threads add new key/value pairs, the data read-to-be-updated increases and hence the number of items to iterate through in the map.
FYI, useRegionBasedMarshalling is set to false.
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/
18 years
RE: [jbosscache-dev] JBCACHE-905 - code coverage for 1.4.1
by Galder Zamarreno
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@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
18 years
RE: [jbosscache-dev] Updating Cache/Node object model in HEAD
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> As per the discussion on the design forum, I'd like to go
> ahead and update this data model in HEAD, perhaps over the
> weekend or early next week.
>
> Just so I don't clash with anyone else's work (since this is
> a big change and is likely to render any code not checked in
> useless and make merging next to impossible), has anyone got
> work that has yet to be checked in? Just want to coordinate
> this with everyone before I go ahead and start making these changes.
>
Go for it. :) And have a happy holidays! Don't fall off any rocks or
anything ;)
18 years
Re: [jbosscache-dev] Updating Cache/Node object model in HEAD
by Manik Surtani
Ok, I'll wait for this anyway in case I end up breaking too much.
--
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 22 Dec 2006, at 14:13, Vladimir Blagojevic wrote:
> Just noticed that state transfer tests got stuck on CC last night. I
> will fix this today and after that I am not having any changes
> pending.
>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>> Manik Surtani
>> Sent: Thursday, December 21, 2006 9:53 PM
>> To: jbosscache-dev(a)lists.jboss.org
>> Subject: [jbosscache-dev] Updating Cache/Node object model in HEAD
>>
>> As per the discussion on the design forum, I'd like to go
>> ahead and update this data model in HEAD, perhaps over the
>> weekend or early next week.
>>
>> Just so I don't clash with anyone else's work (since this is
>> a big change and is likely to render any code not checked in
>> useless and make merging next to impossible), has anyone got
>> work that has yet to be checked in? Just want to coordinate
>> this with everyone before I go ahead and start making these changes.
>>
>> 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
>>
18 years
RE: [jbosscache-dev] Logging exceptions
by Ben Wang
Another thing to add about exception is that we are moving towards runtime exception in 2.0 release (to be in line with the JEE5 approach). Although it is the cache caller that should catch these kind of exceptions but definitely there is higher chance that end users will see some more stack trace.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Friday, December 22, 2006 9:38 AM
To: Brian Stansberry
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Logging exceptions
Precisely. If an exception is bubbled up to the point that the stack trace is dumped, then this is not proper design but a real, unexpected exception.
As Brian suggested, exceptions that are 'expected' (and while this smells of bad design initially, could still be valid if these are truly infrequent circumstances but need appropriate reaction) would probably be also caught by design, and dealt with.
If you are referring to purposefully dumping a stack trace as a part of handling this exception, then keep this to DEBUG or below, as this
*does* freak users out! :-)
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
On 21 Dec 2006, at 19:08, Brian Stansberry wrote:
> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>> Hi,
>>
>> Sometimes I come across a case where a good design principle for a
>> flow of control is to raise an exception. Exceptions are usually
>> logged and stack trace is dumped. In some of these cases exceptions
>> happen due to expected circumstances (i.e request to activate region
>> when region is not active) and so on. I am getting an impression
>> (maybe a false one) that users freak out when the see stack traces
>> and thus I am reluctant to raise an Exception in some of these cases
>> and make a workaround.
>>
>> What do you guys do about this problem? Is there a way to have a
>> generic catch clause for Exception but somehow indicate if stacktrace
>> should be dumped or not to a logger?
>> Or should I just forget about this impression (of freaking out users)
>> and raise exceptions whenever a good design dictates it?
>>
>
> If the exception is raised for a good design purpose, wouldn't that
> also mean it should be handled somewhere and not propagate to
> arbitrary code?
> And then proper logging design means it shouldn't be logged anywhere
> on the way to wherever it's handled, or at least not at anything above
> DEBUG level.
>
> - Brian
>
>
> _______________________________________________
> 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
18 years
Updating Cache/Node object model in HEAD
by Manik Surtani
As per the discussion on the design forum, I'd like to go ahead and
update this data model in HEAD, perhaps over the weekend or early
next week.
Just so I don't clash with anyone else's work (since this is a big
change and is likely to render any code not checked in useless and
make merging next to impossible), has anyone got work that has yet to
be checked in? Just want to coordinate this with everyone before I
go ahead and start making these changes.
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
2.0.0.Alpha2
by Manik Surtani
Guys,
I'm hoping to get HEAD in a state that pretty soon after the holidays
(thinking end of week 1 of Jan) we can tag 2.0.0.ALPHA2. This will
include the new interfaces discussed on the forums, along with all
else tagged for this release in JIRA.
Could you guys have a look at stuff assigned and see if this is
feasible? This will include stabilising current failures on cruise
control as well.
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
RE: [jbosscache-dev] Logging exceptions
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hi,
>
> Sometimes I come across a case where a good design principle
> for a flow of control is to raise an exception. Exceptions
> are usually logged and stack trace is dumped. In some of
> these cases exceptions happen due to expected circumstances
> (i.e request to activate region when region is not active)
> and so on. I am getting an impression (maybe a false one)
> that users freak out when the see stack traces and thus I am
> reluctant to raise an Exception in some of these cases and
> make a workaround.
>
> What do you guys do about this problem? Is there a way to
> have a generic catch clause for Exception but somehow
> indicate if stacktrace should be dumped or not to a logger?
> Or should I just forget about this impression (of freaking
> out users) and raise exceptions whenever a good design dictates it?
>
If the exception is raised for a good design purpose, wouldn't that also
mean it should be handled somewhere and not propagate to arbitrary code?
And then proper logging design means it shouldn't be logged anywhere on
the way to wherever it's handled, or at least not at anything above
DEBUG level.
- Brian
18 years