JBCACHE-315
by Vladimir Blagojevic
Hey guys,
It is becoming more and more obvious to me that porting JBCACHE-315
solution to 1.4 branch is not going to be an easy task. Let me
elaborate. Requirements for JBCACHE-315 as far as JGroups goes are all
in place. However, only HEAD branch of JBC has all other prerequisites
that allow direct implementation of JBCACHE-315 in a reasonable time
frame for our release dates. JBC 1.4 branch is a different story. 1.4
branch does not have partial state transfer implemented on top native
JGroups partial state mechanism - it uses RPC based mechanism with
additional support framework (activation queues etc).
If we really have to have JBCACHE-315 in 1.4.1 GA in time we have to add
some additional resource to help me out. For example, we can have Brian
assist me on JBCACHE-315 while I port partial state transfer from HEAD
to 1.4 branch. Brian is overflowed with work already. Having JBCACHE-315
in 1.4 branch would require configuration stack change to include FLUSH.
We have to do testing for that as well as regressions testing for
replacement of old partial state transfer. A bit risky so close to
release.
Do you have some ideas how we can squeeze JBCACHE-315 in 1.4.1 or should
we include it only in HEAD?
Vladimir
17 years, 7 months
RE: [jbosscache-dev] JBCACHE-315
by Brian Stansberry
My whole motivation for initially bringing this up was a desire for
increased stability in the 4.2 AS release. Sounds like this may bring
*decreased* stability since it involves too much done too quickly. Geez,
suddenly it's December 6!
So, I've no objection to not doing it in 1.4.1.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hey guys,
>
> It is becoming more and more obvious to me that porting
> JBCACHE-315 solution to 1.4 branch is not going to be an easy
> task. Let me elaborate. Requirements for JBCACHE-315 as far
> as JGroups goes are all in place. However, only HEAD branch
> of JBC has all other prerequisites that allow direct
> implementation of JBCACHE-315 in a reasonable time frame for
> our release dates. JBC 1.4 branch is a different story. 1.4
> branch does not have partial state transfer implemented on
> top native JGroups partial state mechanism - it uses RPC
> based mechanism with additional support framework (activation queues
> etc).
>
> If we really have to have JBCACHE-315 in 1.4.1 GA in time we
> have to add some additional resource to help me out. For
> example, we can have Brian assist me on JBCACHE-315 while I
> port partial state transfer from HEAD to 1.4 branch. Brian is
> overflowed with work already. Having JBCACHE-315 in 1.4
> branch would require configuration stack change to include FLUSH.
> We have to do testing for that as well as regressions testing
> for replacement of old partial state transfer. A bit risky so close
> to release.
>
> Do you have some ideas how we can squeeze JBCACHE-315 in
> 1.4.1 or should we include it only in HEAD?
>
> Vladimir
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
RE: JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
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
17 years, 7 months
RE: [jbosscache-dev] Restructuring o.j.c.l.JDBCCacheLoaderPerfTest, thoughts?
by Galder Zamarreno
You're right actually, putting them into a single method would make profiling harder as it wouldn't be that obvious to see the benefits your changes could have in the put area, or get area...etc.
If we added that put loop at the beginning of get and remove methods, it'd distort the profiling results of that tests, wouldn't they?
I'm rolling back on my initial thoughts actually. We could still control the flow implementing the "public static Test suite()" method and leave the tests independent to make profiling easier which is their objective.
I'll change the remove on tear down to evict to still benefit from the original puts.
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: 06 December 2006 12:25
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Restructuring o.j.c.l.JDBCCacheLoaderPerfTest, thoughts?
On 6 Dec 2006, at 10:32, Galder Zamarreno wrote:
> Hi,
>
>
>
> Over the last few days I have been having a look at
> o.j.c.l.JDBCCacheLoaderPerfTest and I have come to the conclusion
> that it needs changing.
>
>
> Currently there're 3 tests, testPut(), testGet() and testRemove().
> I tried running it and I realised that testPut() would do its job
> but the other two would never find anything in the database.
>
>
>
> This could be controlled via setting drop table to false, but this
> would still not work as cache.remove("/") is called on teardown().
>
>
>
> These three tests are quite linked to each other as you expect puts
> to go first, then gets and lastly removes. When running unit tests,
> you're not guaranteed order and taking in account the relationship
> between the tests, I think the code inside these tests should be
> joined into just one test.
>
>
>
> Of couse, you'd need to evict the cache in between puts/gets and
> gets/removes so that you can actually exercise the code fully right
> up to the cache loader.
>
>
>
> Any thoughts?
Yes, something moving to TestNG would help with someday - finer
grained control over test setup and teardown structures as well as
the relationships between tests.
Keep in mind though, the purpose of this test is not like other unit,
stress or perf tests. It does not exercise functionality nor look
for bugs/leaks over time, nor measure any meaningful benchmarks. It
is simply an exercise to micro-bench individual operations so that,
while tuning the cacheloader code, you can measure the effect of your
enhancements. So this really should be treated more as a tuning tool
than anything else (and probably should be excluded from the cruise
control test suite as it is meaningless when run in CC)
And treating it as such a tool, the put, get and remove test methods
should be treated separately IMO. Moving them into a single method
may make profiling a bit hard. I see your point about setting up the
cache with proper data for get and remove tests though; perhaps
include a put loop at the start of get and remove to init the cache
first?
>
>
> 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/
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 7 months
RE: [jbosscache-dev] FC in etc/META-INF protocol stacks
by Brian Stansberry
Manik Surtani wrote:
> On 5 Dec 2006, at 23:42, Brian Stansberry wrote:
>
>> I noticed today that in etc/META-INF we don't have FC in the protocol
>> stack for the ASYNC based configs. That's bad practice. I fixed that
>> in the 3 "replAsync..." files, but we should probably look at all of
>> these in terms of whether they provide good examples to people who
>> look at them. A lot of them are written for test cases and probably
>> aren't careful about things that don't affect the relevant test.
>
>
> Did you fix these in 1.4 or HEAD?
Both.
>
>>
>> Also there's an optimal-for-large-cluster-http-session-service.xml
>> that uses INVALIDATION_SYNC. That won't work, at least not with
>> JBoss session clustering.
>
> Yes, with BR in place this file is obsolete. I guess just
> remove this, since we have a BR configuration available as well?
>
+1
- Brian
17 years, 7 months
Restructuring o.j.c.l.JDBCCacheLoaderPerfTest, thoughts?
by Galder Zamarreno
Hi,
Over the last few days I have been having a look at o.j.c.l.JDBCCacheLoaderPerfTest and I have come to the conclusion that it needs changing.
Currently there're 3 tests, testPut(), testGet() and testRemove(). I tried running it and I realised that testPut() would do its job but the other two would never find anything in the database.
This could be controlled via setting drop table to false, but this would still not work as cache.remove("/") is called on teardown().
These three tests are quite linked to each other as you expect puts to go first, then gets and lastly removes. When running unit tests, you're not guaranteed order and taking in account the relationship between the tests, I think the code inside these tests should be joined into just one test.
Of couse, you'd need to evict the cache in between puts/gets and gets/removes so that you can actually exercise the code fully right up to the cache loader.
Any thoughts?
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/
17 years, 7 months
FC in etc/META-INF protocol stacks
by Brian Stansberry
I noticed today that in etc/META-INF we don't have FC in the protocol
stack for the ASYNC based configs. That's bad practice. I fixed that in
the 3 "replAsync..." files, but we should probably look at all of these
in terms of whether they provide good examples to people who look at
them. A lot of them are written for test cases and probably aren't
careful about things that don't affect the relevant test.
Also there's an optimal-for-large-cluster-http-session-service.xml that
uses INVALIDATION_SYNC. That won't work, at least not with JBoss
session clustering.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
RE: JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
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.
>>
>> 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.
>>
>> 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.
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.
- Brian
17 years, 7 months
JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
Manik Surtani wrote:
> Yeah, I may do a CR1 tomorrow anyway, and get JBCACHE-315 and JGroups
> 2.4.1 in CR2 now. There are enough changes from fixing
> JBCACHE-871 and JBCACHE-875 to warrant a CR, as these are
> pretty big changes.
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.
This is a switch from LinkedList to LinkedHashSet as the data structure
in TransactionEntry; there's a forum post linked to the JIRA that
explains why.
I can probably do this today, but wanted to point out a couple things
and get feedback:
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?
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);"
If there are any concerns about this, it doesn't need to get done today
or go in CR1.
- Brian
17 years, 7 months
RE: JBossCache_1_3_0_SP4 tagged for release
by Ryan Campbell
This is scheduled to be done by Friday.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Monday, December 04, 2006 5:05 AM
> To: jbosscache-dev(a)lists.jboss.org
> Cc: QA
> Subject: JBossCache_1_3_0_SP4 tagged for release
>
> See
>
> http://jira.jboss.com/jira/browse/JBQA-580
>
> And the changelog is here:
>
> http://tinyurl.com/yfw73u
>
> 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
>
>
>
17 years, 7 months
