JBossCache 1.4.1.Beta
by Manik Surtani
Guys, I'm hoping to tag this release on Friday AM my time. QA, do
you think you'd be able to do this release on Fri?
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, 6 months
RE: Mismatch between TreeCache and DistributedState listeners
by Brian Stansberry
Copying the jbosscache-dev list as this ties in with an ongoing
conversation there re: how nodeModified should work in 2.0. Jerry, I've
forwarded the thread to you.
My answer really depends on how that discussion turns out, so let's hope
we can resolve it quicky. If JBC 2.0 is going to start providing the
info you need in the nodeModified callback, #1 makes more sense (since
JBC will do the work for you). Otherwise #2, with the value stored in
the key's map. Downsides to #2 are RAM overhead of adding an extra node
per key, plus different locking semantics.
Jerry Gauthier wrote:
> I've discovered a mismatch between the TreeCache and
> DistributedState listeners. On the DS side, the modification
> and removal events identify the category, key and value
> applicable to the event. This worked fine in 4.x with the
> non-TreeCache based implementation.
>
> With the TreeCache based implementation in 5.0, events are
> handled without any problems on the local node. However
> events that occur on remote nodes are passed to the DS
> implementation via cache events. The granularity of cache
> events is restricted to identifying nodes that have been
> modified. The cache events don't identify the keys or values
> that have been modified or removed.
>
> Looking closer at DistributedStateImpl, I see that in several
> places the authors assumed that keys would be stored as
> nodes. But the set method is implemented as
> cache.put(category, key, value) which clearly stores the key in the
> node's map.
>
> It seems that there are two possible solutions here, assuming
> we want to have the DS listeners provide the same information as
> before.
>
> 1) When DSImpl receives NodeModify and NodeRemove events, it
> can store the pre and post data maps and then compare to
> determine what's actually changed.
>
> 2) We can store all keys as child nodes of the category
> nodes. Then values can either be children of the keys or
> stored in the key's map.
17 years, 6 months
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Brian Stansberry
Thanks, Ryan. JIRA is http://jira.jboss.com/jira/browse/JBQA-536.
Ryan Campbell wrote:
> I don't think we can do it for this release (by this week),
> but if you will raise a JBQA, I will schedule it.
>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Friday, October 27, 2006 11:55 AM
>> To: Manik Surtani; jbosscache-dev(a)lists.jboss.org
>> Cc: QA
>> Subject: RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
>>
>> Also, for a next 1.4 release we really should add serialVersionUID
>> compatibility tests like the AS has. Is there anyone in QA who
>> could help with that?
>>
>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>> Brian and I have been speaking about adding JBCACHE-812 to the next
>>> 1.4.x release, the purpose being that there may be an AS 4.2.0
>>> release which may allow us to include the MUX.
>>>
>>> Since this is a fairly large feature change, I feel it is beyond the
>>> scope of an SP and would warrant a bump up in version numbers. And
>>> TBH, so does JBCACHE-756, since it involves a new JBoss
>>> Serialization jar.
>>>
>>> Thoughts on this? Pls respond soon as I hope to cut the next
>>> 1.4 release next week.
>>>
>>> Cheers,
17 years, 6 months
RE: [jbosscache-dev] JBCACHE-388 Provide modified data in callbacks
by Ben Wang
Yes, I did realize that. But implementation wise, it should be straightforward since Cache knows exactly the identifier, right? We just need to add an "identifier" enum in the nodeModified callback. Downside is one more parameter but upside is faster processing such that we don't hog the calling thread.
-----Original Message-----
From: Manik Surtani [mailto:msurtani@redhat.com]
Sent: Monday, October 30, 2006 11:15 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data in callbacks
Well, nodeModified covers 3 scenarios:
1) Data added to map
2) Data removed from map
3) Existing map data changed
if we just passed in deltas, we'd also need to pass in keys to describe the operation. I.e., a nodeVisited event could pass in a key-value pair, but we'd also need to pass in an identifier to describe the modification. Which makes it pretty tedious. This is why I opted for just passing a snapshot of the state of data before and after the mod.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: msurtani(a)redhat.com
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 29 Oct 2006, at 16:20, Ben Wang wrote:
> Yes, are are right. Silly me, I was looking at the pre only.
>
> Still, my question is that will it make more sense during post-
> nodeModified notification to deliver only the data modified (not the
> new data map). If I am only interested what portion of my data has
> been modified (and I belive this is a quite common use case), then I
> would need to keep an old data map and diff it with the new data map.
> Doable but it would be a performance killer for sure.
>
> Thanks,
>
> -Ben
>
> -----Original Message-----
> From: Manik Surtani [mailto:msurtani@redhat.com]
> Sent: Friday, October 27, 2006 11:14 PM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data in
> callbacks
>
> Is this when pre is true or false?
>
> If pre is true, the data will be the old data. If pre is false, it
> will be the new data.
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: msurtani(a)redhat.com
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 27 Oct 2006, at 13:47, Ben Wang wrote:
>
>> Manik,
>>
>> Can you clarify the semantics for the modified callbacks?
>> Specifically, I am looking at the test case:
>> CacheListenerTest.testRemoveData()
>> calling
>> cache.remove(fqn, "key2");
>> Still has the nodeModified() coming with the original data map. Is
>> this the expected behavior?
>>
>> I am hoping to see a semantics that bundles exactly the modified
>> data.
>>
>> Thanks,
>>
>> -Ben
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
17 years, 6 months
RE: [jbosscache-dev] JBCACHE-388 Provide modified data in callbacks
by Ben Wang
Yes, are are right. Silly me, I was looking at the pre only.
Still, my question is that will it make more sense during post-nodeModified notification to deliver only the data modified (not the new data map). If I am only interested what portion of my data has been modified (and I belive this is a quite common use case), then I would need to keep an old data map and diff it with the new data map. Doable but it would be a performance killer for sure.
Thanks,
-Ben
-----Original Message-----
From: Manik Surtani [mailto:msurtani@redhat.com]
Sent: Friday, October 27, 2006 11:14 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBCACHE-388 Provide modified data in callbacks
Is this when pre is true or false?
If pre is true, the data will be the old data. If pre is false, it will be the new data.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: msurtani(a)redhat.com
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 27 Oct 2006, at 13:47, Ben Wang wrote:
> Manik,
>
> Can you clarify the semantics for the modified callbacks?
> Specifically, I am looking at the test case:
> CacheListenerTest.testRemoveData()
> calling
> cache.remove(fqn, "key2");
> Still has the nodeModified() coming with the original data map. Is
> this the expected behavior?
>
> I am hoping to see a semantics that bundles exactly the modified data.
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 6 months
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Galder Zamarreno
+1 on 1.4.1.
Has any progress been made in JBossCache as 2nd level cache for Hibernate? I've seen quite a few customers least than happy in the last week or so.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 27 October 2006 13:31
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
Brian and I have been speaking about adding JBCACHE-812 to the next
1.4.x release, the purpose being that there may be an AS 4.2.0
release which may allow us to include the MUX.
Since this is a fairly large feature change, I feel it is beyond the
scope of an SP and would warrant a bump up in version numbers. And
TBH, so does JBCACHE-756, since it involves a new JBoss Serialization
jar.
Thoughts on this? Pls respond soon as I hope to cut the next 1.4
release next week.
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, 6 months
RE: [jbosscache-dev] Re: 1.4.0.SP2 or 1.4.1?
by Galder Zamarreno
Tbh, I think I've only seen it in being asked in one case. I don't think it's top priority.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 27 October 2006 13:34
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Re: 1.4.0.SP2 or 1.4.1?
Also,
JBCACHE-684 has been made in HEAD - any thoughts on whether this
should be backported to 1.4.x? It is easy enough, and I have seen
people hit this hard limit in eviction queues often enough in support
cases. Galder, thoughts? Is this something a lot of customers would
find helpful in a 1.4 release?
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 27 Oct 2006, at 12:31, Manik Surtani wrote:
> Brian and I have been speaking about adding JBCACHE-812 to the next
> 1.4.x release, the purpose being that there may be an AS 4.2.0
> release which may allow us to include the MUX.
>
> Since this is a fairly large feature change, I feel it is beyond
> the scope of an SP and would warrant a bump up in version numbers.
> And TBH, so does JBCACHE-756, since it involves a new JBoss
> Serialization jar.
>
> Thoughts on this? Pls respond soon as I hope to cut the next 1.4
> release next week.
>
> 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, 6 months
RE: [jbosscache-dev] Consistent factory method
by Ben Wang
Yes, if we want to keep things simple actually static method is probably
it. Key is I don't see other usage of Cache factory class now so I agree
with Brian's 99% assement (it is also certainly true for PojoCache).
-Ben
-----Original Message-----
From: Brian Stansberry
Sent: Saturday, October 28, 2006 12:03 AM
To: Ben Wang; Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] Consistent factory method
I prefer both ;-) Perhaps add a class to o.j.c.factories that creates a
singleton DefaultCacheFactory and exposes static methods? If people
don't want to use it, that's fine, but it's there for the 99.9% use
case. An issue is what to name it.
Static is a bit easier to understand when using the MC as it eliminates
an extra bean instantiation.
Static:
<bean name="MyCacheConfig" class="org.jboss.cache.config.Configuration">
....
</bean>
<bean name="MyCache">
<constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory"
factoryMethod="createInstance">
<parameter class="org.jboss.cache.config.Configuration"><inject
bean="MyCacheConfig"/></parameter>
<parameter>false</parameter>
</constructor>
</bean>
Instance:
<bean name="MyCacheConfig" class="org.jboss.cache.config.Configuration">
....
</bean>
<bean name="MyCacheFactory"
class="org.jboss.cache.factories.DefaultCacheFactory"/>
<bean name="MyCache">
<constructor factoryMethod="createCache">
<factory bean="MyCacheFactory"/>
<parameter class="org.jboss.cache.config.Configuration"><inject
bean="MyCacheConfig"/></parameter>
<parameter>false</parameter>
</constructor>
</bean>
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Ic. So what do other people prefer, if we can do it either way?
>
> -----Original Message-----
> From: Manik Surtani [mailto:msurtani@redhat.com]
> Sent: Thursday, October 26, 2006 9:17 PM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Consistent factory method
>
> Nothing more than the factory is a simple class. If user code wants
> to wrap it in a singleton and create factory methods in the wrapper,
> it is up to them. Just keeping things simple.
>
>
>> Manik,
>>
>> This is a minor issue raised by Brian when he is constructing the
>> bean file for AS5. Currently, we have slight way of creating a cache
>> instance from the factory method.
>>
>> In Cache, we do:
>>
>> CacheFactory factory = new DefaultCacheFactory();
>> CacheSPI tree = (CacheSPI) factory.createCache(c, false);
>>
>> While in PojoCache, we do:
>> cache_ = PojoCacheFactory.createInstance(configFile, false);
>>
>> Nothing wrong with both approaches but maybe we should be consistent
>> in both cache instances. And I don't mind to switch if needed. For
>> me, the reason that I did it in the first place is I don't forsee a
>> pluggable cache instance for PojoCache. And if needed, another
>> Factory can be used as well.
>>
>> I thought originally with your approach, there is more control over
>> the lifecycle methods. But now it is probably not needed there. Any
>> other reason to stick with your approach?
>>
>> Thanks,
>>
>> -Ben
17 years, 6 months
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Brian Stansberry
I don't recall mux-specific testing, but I wasn't too involved back
then. Jerry, do you recall what can of mux-related testing was added to
1.4?
Perhaps something like this would work as a good base:
1) Create an ant patternset of the existing tests we want to run, but
now with mux. Idea is to re-use existing tests to confirm functionality
of things like state transfer, replication, buddy group formation.
2) Add the mux channel configs to the configs used by those tests. Set
it to a system property. AIUI, if the property is not set, the mux
config will not work and the cache will fall back on the old protocol
stack config. So existing tests still work.
3) Create a new target in build.xml that runs the tests in the
patternset from #1. The target sets the system property.
Crap -- the mux factory is an mbean -- for this to work the tests need
an mbean server. Well, maybe the above will spark an idea from someone
else.
- Brian
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> No testing yet. We are about to test jbc head for regression
> problems in 2.4. We can include jbc 1.4 branch in the same
> process. I am not sure how mux based testing is done in jbc
> 1.4 branch. Brian might be familiar with this?
>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
>> Sent: Friday, October 27, 2006 7:51 AM
>> To: Manik Surtani
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
>>
>> Has any testing been done on 812 ? Vlad ?
>> Yes, I think this warrents another version number, not just an SP
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 6 months
RE: [jbosscache-dev] 1.4.0.SP2 or 1.4.1?
by Brian Stansberry
Also, for a next 1.4 release we really should add serialVersionUID
compatibility tests like the AS has. Is there anyone in QA who could
help with that?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Brian and I have been speaking about adding JBCACHE-812 to
> the next 1.4.x release, the purpose being that there may be
> an AS 4.2.0 release which may allow us to include the MUX.
>
> Since this is a fairly large feature change, I feel it is
> beyond the scope of an SP and would warrant a bump up in
> version numbers. And TBH, so does JBCACHE-756, since it
> involves a new JBoss Serialization jar.
>
> Thoughts on this? Pls respond soon as I hope to cut the next
> 1.4 release next week.
>
> Cheers,
17 years, 6 months
