JBCACHE-815
by Manik Surtani
Brian,
Do you feel this needs to be a config option, or can we live with a -
D setting to disable jboss serialization? I know I originally
suggested a proper config elem for this, but since the
ObjectSerializationFactory uses a static method, passing in a
Configuration object here would be a pita.
What do you think?
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
Cache.remove() return value
by Brian Stansberry
Any reason Cache.remove(Fqn, Object) is a void return instead of the
prior value for the key? That breaks compatibility with old code.
Node.remove(Object) and TreeCache.remove(Fqn, Object) both return the
old value so I suspect the void return from Cache wasn't intentional.
- Brian
18 years
Re: [jbosscache-dev] State transfer tests in head
by Manik Surtani
This was actually from a series of IM and phone conversations I had
with Brian around RegionManagers and Marshalling/Eviction Regions.
In the 1.x codebase, marshalling regions would queue calls made to
regions marked as inactive, and then apply these calls when the
region was activated. Sort of a way to deal with calls that may come
in to a cache before the cache has completed transferring state and
fully joins the cluster. We felt that with FLUSH in place, we'd have
a better solution. If this otherwise edge case starts becoming a
concern, enabling FLUSH would be the correct solution.
--
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 31 Oct 2006, at 17:12, Vladimir Blagojevic wrote:
> Ok thanks Brian. I do not remember "replacing queueing with FLUSH"
> but I
> was not focused on that back then. I'll look.
>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Tuesday, October 31, 2006 12:08 PM
>> To: Vladimir Blagojevic; Manik Surtani
>> Subject: RE: [jbosscache-dev] State transfer tests in head
>>
>> If you look through e-mails I sent a couple months back when
>> we were attacking the siemens issue, there was one that had a
>> bunch of forum links.
>>
>> Vladimir Blagojevic wrote:
>>> Hey guys,
>>>
>>> I have this task on my plate now that Jgroups has been cleared up a
>>> bit. I also have to implemented partial state transfer as jgroups
>>> getState call rather than rpc invocation.
>>> I have already started coding on partial state transfer. Task that
>>> Manik mentions below is very much related since
>>> TreeCache.activateRegion is initiating partial state transfer.
>>>
>>> Would one of you, when you get a chance, give me a bit more
>> background
>>> pointers about .
>>> Anything will do: forum references, JIRA etc etc.
>>>
>>> Vladimir
>>>
>>>
>>>> -----Original Message-----
>>>> From: jbosscache-dev-bounces(a)lists.jboss.org
>>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik
>>>> Surtani Sent: Friday, October 13, 2006 8:38 AM
>>>> To: jbosscache-dev(a)lists.jboss.org
>>>> Subject: [jbosscache-dev] State transfer tests in head
>>>>
>>>> Hi,
>>>>
>>>> As a part of refactoring the marshall.Region class to a generic
>>>> Region which can be used for eviction as well, Brian and I
>> discussed
>>>> removing queueing of calls to inactive regions, since this
>> would be
>>>> replaced with FLUSH. As such, I've commented out a few unit tests
>>>> that test this queueing in VersionedTestsBase and have commented
>>>> accordingly. Vladimir, once we roll in FLUSH and have this
>> working as
>>>> expected, could you revisit these tests in state transfer?
>>>>
>>>> Thanks,
>>>> --
>>>> 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
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
18 years
Re: [jbosscache-dev] Re: JBossCache 1.4.1.Beta
by Manik Surtani
Sorry, s/Oct/Nov/g
--
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 31 Oct 2006, at 17:11, Vladimir Blagojevic wrote:
> Is England running one month behind the rest of us:)?
>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>> Manik Surtani
>> Sent: Tuesday, October 31, 2006 11:36 AM
>> To: Ryan Campbell
>> Cc: jbosscache-dev(a)lists.jboss.org; QA
>> Subject: [jbosscache-dev] Re: JBossCache 1.4.1.Beta
>>
>> No worries. And as a heads-up, we hope to release:
>>
>> 1.4.1.CR1 - Fri 10th Oct
>> 1.4.1.GA - Fri 17th Oct
>>
>> I know it is a pretty close schedule but 1.4.1 isn't far off
>> from another SP on 1.4.0.
>>
>> Looking into the CC failures.
>>
>> 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 31 Oct 2006, at 16:25, Ryan Campbell wrote:
>>
>>> We can start the release on Friday; can you create the JBQA JIRA
>>> release
>>> issue? Also, we would like to have 2 weeks notice in the future.
>>> This
>>> allows us to plan around any competing priorities.
>>>
>>> I currently see 9 failures in cruisecontrol for the
>>> jboss-cache-testsuite-140 run. We will want these resolved before
>>> release.
>>>
>>> Thanks,
>>> Ryan
>>>
>>>> -----Original Message-----
>>>> From: Manik Surtani [mailto:manik@jboss.org]
>>>> Sent: Tuesday, October 31, 2006 5:50 AM
>>>> To: jbosscache-dev(a)lists.jboss.org
>>>> Cc: QA
>>>> Subject: JBossCache 1.4.1.Beta
>>>>
>>>> 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
>>>>
>>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
18 years
Use of org.jboss.cache.Region
by Brian Stansberry
Hey Manik,
I know you were planning on working with integrating the eviction and
marshalling regions this week. Here's some input based on stuff I'm
doing on converting the EJB3 code to use the 2.0 API.
1) Once I call Cache.getRegion(fqn, true) I've created a Region, but I'm
not sure how to set it up programatically to do eviction. Passing a
config to setEvictionPolicyConfig() seems obvious. But would that be
enough to get the eviction policy created? Or should I then call
activate()? The javadoc implies that activate() pertains to
marshalling, but does it make sense to make it apply to eviction as well
-- a sort of general purpose start() method?
2) Conversely, how to remove a region when an SFSB is undeployed?
There's no Cache.removeRegion(Fqn). There is a deactivate() method.
I realize this stuff may not be implemented; I'm more concerned with
understanding the API.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years
RE: JBossCache 1.4.1.Beta
by Ryan Campbell
Ok, this will work. Thanks, Manik!
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, October 31, 2006 10:51 AM
> To: Ryan Campbell
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: JBossCache 1.4.1.Beta
>
> On 31 Oct 2006, at 16:45, Ryan Campbell wrote:
>
> > Friday releases are impolite to QA who usually end up working well
> > into
> > Friday evening (especially after finding issues which you guys have
to
> > fix ;-).
>
> Good point - my apologies.
>
> >
> > I would rather do releases Monday-Wednesday. Could you able to
update
> > your schedule accordingly? I think we can handle this Friday, but
for
> > future releases I would prefer Monday-Wednesday.
>
> Ok, I could squeeze in something like:
>
> 1.4.1.CR1 - Thu 9th Oct
> 1.4.1.GA - Thu 16th Oct
>
> And thereafter, I'll make sure we do it earlier in the week. Is that
> ok?
>
> Cheers,
> Manik
>
> >
> > Thanks,
> > Ryan
> >
> >> -----Original Message-----
> >> From: Manik Surtani [mailto:manik@jboss.org]
> >> Sent: Tuesday, October 31, 2006 10:36 AM
> >> To: Ryan Campbell
> >> Cc: jbosscache-dev(a)lists.jboss.org; QA
> >> Subject: Re: JBossCache 1.4.1.Beta
> >>
> >> No worries. And as a heads-up, we hope to release:
> >>
> >> 1.4.1.CR1 - Fri 10th Oct
> >> 1.4.1.GA - Fri 17th Oct
> >>
> >> I know it is a pretty close schedule but 1.4.1 isn't far off from
> >> another SP on 1.4.0.
> >>
> >> Looking into the CC failures.
> >>
> >> 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 31 Oct 2006, at 16:25, Ryan Campbell wrote:
> >>
> >>> We can start the release on Friday; can you create the JBQA JIRA
> >>> release
> >>> issue? Also, we would like to have 2 weeks notice in the future.
> >>> This
> >>> allows us to plan around any competing priorities.
> >>>
> >>> I currently see 9 failures in cruisecontrol for the
> >>> jboss-cache-testsuite-140 run. We will want these resolved before
> >>> release.
> >>>
> >>> Thanks,
> >>> Ryan
> >>>
> >>>> -----Original Message-----
> >>>> From: Manik Surtani [mailto:manik@jboss.org]
> >>>> Sent: Tuesday, October 31, 2006 5:50 AM
> >>>> To: jbosscache-dev(a)lists.jboss.org
> >>>> Cc: QA
> >>>> Subject: JBossCache 1.4.1.Beta
> >>>>
> >>>> 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
> >>>>
> >>>
> >
18 years
RE: JBossCache 1.4.1.Beta
by Ryan Campbell
Friday releases are impolite to QA who usually end up working well into
Friday evening (especially after finding issues which you guys have to
fix ;-).
I would rather do releases Monday-Wednesday. Could you able to update
your schedule accordingly? I think we can handle this Friday, but for
future releases I would prefer Monday-Wednesday.
Thanks,
Ryan
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, October 31, 2006 10:36 AM
> To: Ryan Campbell
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: JBossCache 1.4.1.Beta
>
> No worries. And as a heads-up, we hope to release:
>
> 1.4.1.CR1 - Fri 10th Oct
> 1.4.1.GA - Fri 17th Oct
>
> I know it is a pretty close schedule but 1.4.1 isn't far off from
> another SP on 1.4.0.
>
> Looking into the CC failures.
>
> 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 31 Oct 2006, at 16:25, Ryan Campbell wrote:
>
> > We can start the release on Friday; can you create the JBQA JIRA
> > release
> > issue? Also, we would like to have 2 weeks notice in the future.
> > This
> > allows us to plan around any competing priorities.
> >
> > I currently see 9 failures in cruisecontrol for the
> > jboss-cache-testsuite-140 run. We will want these resolved before
> > release.
> >
> > Thanks,
> > Ryan
> >
> >> -----Original Message-----
> >> From: Manik Surtani [mailto:manik@jboss.org]
> >> Sent: Tuesday, October 31, 2006 5:50 AM
> >> To: jbosscache-dev(a)lists.jboss.org
> >> Cc: QA
> >> Subject: JBossCache 1.4.1.Beta
> >>
> >> 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
> >>
> >
18 years
Re: JBossCache 1.4.1.Beta
by Manik Surtani
No worries. And as a heads-up, we hope to release:
1.4.1.CR1 - Fri 10th Oct
1.4.1.GA - Fri 17th Oct
I know it is a pretty close schedule but 1.4.1 isn't far off from
another SP on 1.4.0.
Looking into the CC failures.
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 31 Oct 2006, at 16:25, Ryan Campbell wrote:
> We can start the release on Friday; can you create the JBQA JIRA
> release
> issue? Also, we would like to have 2 weeks notice in the future.
> This
> allows us to plan around any competing priorities.
>
> I currently see 9 failures in cruisecontrol for the
> jboss-cache-testsuite-140 run. We will want these resolved before
> release.
>
> Thanks,
> Ryan
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, October 31, 2006 5:50 AM
>> To: jbosscache-dev(a)lists.jboss.org
>> Cc: QA
>> Subject: JBossCache 1.4.1.Beta
>>
>> 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
>>
>
18 years
JBoss Cache on Fisheye
by Manik Surtani
Hi,
I can't access JBoss Cache stuff since it used to sit under the
"JBoss" repo and this has since been disabled. Can we set up a
direct link to the JBoss Cache repo?
Thanks,
--
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] JBCACHE-388 Provide modified data in callbacks
by Brian Stansberry
How common is the use case where the listener wants to know the
differences? I'd be concerned about the overhead of creating objects to
encapsulate the diff every time there is a change -- just so those
objects can be passed to a CacheListener that ignores the data.
OTOH, even if the current approach of just handing out the new data map
is used, that should at least be a Collections.unmodifiableMap wrapping
the internal data structure, so there's overhead there as well. Probably
a wash, except in the put(Fqn, Map) case, where doing the diff is more
tedious.
I guess I have no strong opinion on this...
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hmm, which approach do people prefer?
>
> And how would a nodeModified event from an operation like put(Fqn,
> Map) be represented, since it may represent both data added
> as well as data modified? I don't think this should result
> in multiple callbacks.
>
> Cheers,
>
>
>> 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
18 years