RE: [jbosscache-dev] Notification interceptor
by Ben Wang
Bela is right. One other thing that I remember to discuss was to batch the notification events under tx (if there is one). It is only doable if it is done in a notification interceptor, perhaps.
For current PojoCache impl, I was originally gunning for a notification interceptor, but had to abandon it because of granularity. For instance, if I do a detach(id), I should emit an pre- and post- notification if it return a POJO. But if it returns null (meaning no POJO is associated with that ID), there should be no need for a notification event. Of course, it is suffering the same problem of tx rollback.
So if there is a good methodology, I can adopt it as well.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
Sent: Sunday, September 17, 2006 3:50 AM
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Notification interceptor
Let's find the bits and pieces of emails between us and Hany, we discussed this feature in great detail. IIRC, one of the issues was that there was no real good place for the NotificationInterceptor, in some cases towards the top would have been okay, in some not. Example:
CacheLoader/Store interceptor: those methods don't get passed up, so a NotifInt towards the top would not be able to catch them.
But, yes, we need to start thinking about having all notifications emitted from one place, so let's kick-start that thought process again.
Even if we end up having only 95% of all notifications emitted from the interceptor, and the rest directly, that would be fine too.
Manik, maybe it is a good idea to involve Hany again, because he was involved real deep before... I'm sure he remembers some of the discussions...
Manik Surtani wrote:
> Hi,
>
> There was talk of a separate notification interceptor some while back.
> What happened around this?
>
> Looking at wiring in the relevant notifications for move() and realise
> what a PITA it is with notification calls scattered all over the code
> base.
>
> I think an interceptor at (or close to) the head of the chain to fire
> notifications would be quite straightforward and easy - pre and post
> notifications would be easily handled. The only notification that
> would originate outside of this interceptor would be
> load/evict/activate/passivate notifications ...
>
> What do people 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
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
--
Bela Ban
Lead JGroups / Manager JBoss Clustering Group JBoss - a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years, 1 month
More breaking UTs in HEAD
by Manik Surtani
Hi guys
The reason for a higher failure rate in CC is that I added a whole
bunch of unit tests to stress the new move() API in various ways.
Some of these need fixing (such as deep locks on nodes when moving
subtrees and optimistic locks on subtrees, notifications while
moving, and cacheloader/passivation code to reflect moves) but I
expect these to be in place Monday.
Just in case you were wondering why the test pass-rate dropped from
98.5% to 92.5%! :-)
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
20 years, 1 month
CruiseControl
by Manik Surtani
Hi, I noticed that CC did not run the JBC testsuite last night. Any
idea what's up?
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
20 years, 1 month
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Galder Zamarreno
Oh, sorry, I was referring to in-memory state, not the one in the cache loader. Forget about my last comment.
Galder Zamarreño
Support 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 Galder Zamarreno
Sent: 14 September 2006 12:30
To: Manik Surtani; Vladimir Blagojevic
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
I like the idea.
That's what I actually did for the SingletonCacheLoader when I wanted to get the in-memory state. Instead of using the getState() methods in TreeCache, I recursively called get/puts.
It would definitely make things a lot simple :-)
Galder Zamarreño
Support 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: 12 September 2006 14:31
To: Vladimir Blagojevic
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
If we're implementing store/loadState in an AbstractCacheLoader
(which uses gets/puts anyway), then why not move this code into the
interceptor and ditch the store/loadState methods from the
CacheLoader interface?
Hmm, trying to think of why this may not be a good thing ...
--
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 12 Sep 2006, at 14:25, Vladimir Blagojevic wrote:
>
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, September 12, 2006 4:21 AM
>> To: Bela Ban
>> Cc: Vladimir Blagojevic; jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
>> I agree with this - but just to re-iterate, the only
>> improvement here
>> is formalising the format of state stored in the loaders, am
>> I correct?
>>
>> Or is it more like removing load/store state methods on the cache
>> loader interface altogether and let the interceptors deal with this
>> using loader.put()/get() calls - since this is what happens
>> internally (within the cloader impl) anyway?
>>
>
> I am not sure how Bela envisioned that cacheloader can be
> refactored to
> interceptor but I suppose it is possible. What we talked about was
> having
> generic cacheloader storeState Method in AbstractCacheLoader.
> StoreState
>
> can be generic since we simply read NodeData objects from stream and
> call
> put on underlying cacheloader. I suppose we can also make generic
> loadState
> that only relies on cacheloader's get method and a recursive call.
> That
> would
> be cool. But yes cacheloaders are getting simpler and easier to
> implement :)
_______________________________________________
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
20 years, 1 month
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Galder Zamarreno
I like the idea.
That's what I actually did for the SingletonCacheLoader when I wanted to get the in-memory state. Instead of using the getState() methods in TreeCache, I recursively called get/puts.
It would definitely make things a lot simple :-)
Galder Zamarreño
Support 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: 12 September 2006 14:31
To: Vladimir Blagojevic
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
If we're implementing store/loadState in an AbstractCacheLoader
(which uses gets/puts anyway), then why not move this code into the
interceptor and ditch the store/loadState methods from the
CacheLoader interface?
Hmm, trying to think of why this may not be a good thing ...
--
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 12 Sep 2006, at 14:25, Vladimir Blagojevic wrote:
>
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, September 12, 2006 4:21 AM
>> To: Bela Ban
>> Cc: Vladimir Blagojevic; jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
>> I agree with this - but just to re-iterate, the only
>> improvement here
>> is formalising the format of state stored in the loaders, am
>> I correct?
>>
>> Or is it more like removing load/store state methods on the cache
>> loader interface altogether and let the interceptors deal with this
>> using loader.put()/get() calls - since this is what happens
>> internally (within the cloader impl) anyway?
>>
>
> I am not sure how Bela envisioned that cacheloader can be
> refactored to
> interceptor but I suppose it is possible. What we talked about was
> having
> generic cacheloader storeState Method in AbstractCacheLoader.
> StoreState
>
> can be generic since we simply read NodeData objects from stream and
> call
> put on underlying cacheloader. I suppose we can also make generic
> loadState
> that only relies on cacheloader's get method and a recursive call.
> That
> would
> be cool. But yes cacheloaders are getting simpler and easier to
> implement :)
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years, 1 month
RE: [jbosscache-dev] Re: Logging jars
by Galder Zamarreno
Did u know that you can know download a bundle of NetBeans with JBoss Application Server? Definitely gotta try that....not! ;-)
Galder Zamarreño
Support 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: 11 September 2006 21:55
To: Bela Ban
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Re: Logging jars
The ant scripts already do this. It is just the IDE configs that
need manual re-setting - although only once, as IDE config files can
be checked into CVS as well (Eclipse and IntelliJ - and don't tell me
someone's using NetBeans, coz I won't believe you!!)
--
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 11 Sep 2006, at 21:46, Bela Ban wrote:
> I'm all for version numbers in JARs, but we also need scripts that
> add (e.g.) all JARs in a given dir to the classpath, rather than
> list them. If we list them explicitly, we have to change those
> scripts when we change the JAR name.
>
> Manik Surtani wrote:
>> I was trying it out as per our discussions on dev.
>>
>> Also, I think it is best to have version numbers on such jars just
>> so we're clear on what versions we're using (I couldn't tell which
>> version of JCL we had before, for example)
>>
>> What does everyone think about version numbers in the jars we use,
>> like this?
>>
>> 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 11 Sep 2006, at 18:29, Brian Stansberry wrote:
>>
>>> Hey dude,
>>>
>>> Looks like you checked in commons-logging-1.1.jar and
>>> log4j-1.2.13.jar.
>>> Was this intentional? These files have a different name from
>>> what's in
>>> the Eclipse project classpath, so that breaks Eclipse. I can
>>> check in a
>>> fixed Eclipse .classpath file, but don't want to if you're going to
>>> revert the library change.
>>>
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group
> JBoss - a division of Red Hat
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years, 1 month
RE: [jbosscache-dev] Re: Logging jars
by Galder Zamarreno
++1
Galder Zamarreño
Support 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: 11 September 2006 18:40
To: Brian Stansberry
Cc: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Re: Logging jars
I was trying it out as per our discussions on dev.
Also, I think it is best to have version numbers on such jars just so
we're clear on what versions we're using (I couldn't tell which
version of JCL we had before, for example)
What does everyone think about version numbers in the jars we use,
like this?
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 11 Sep 2006, at 18:29, Brian Stansberry wrote:
> Hey dude,
>
> Looks like you checked in commons-logging-1.1.jar and
> log4j-1.2.13.jar.
> Was this intentional? These files have a different name from
> what's in
> the Eclipse project classpath, so that breaks Eclipse. I can check
> in a
> fixed Eclipse .classpath file, but don't want to if you're going to
> revert the library change.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years, 1 month
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Galder Zamarreno
I have implemented the SingletonCacheLoader for 1.2.4.x but I need to port it to 2.0.0 (http://jira.jboss.com/jira/browse/JBCACHE-650)
Galder Zamarreño
Support 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: 11 September 2006 17:00
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
Hi guys
A quick email to talk about releasing an alpha on 2.0.0 to gather
some feedback from implementors like Hibernate/Clustering/etc.
CC currently runs with a 91% success rate.
* o.j.c.buddyreplication - some failures, I'm working on this today
* o.j.c.loader - the TcpCacheLoader still has a failure around state
transfer. Vladimir, what's the current feel on this, is this the
load/store issue you mentioned?
* o.j.c.marshall - the large String issue, which turned out to be a
bug in JBoss Serialization. Clebert's looking into fixing this and
issuing a new jboss-serialization jar.
* o.j.c.statetransfer - I'm working on these today as well
* o.j.c.transaction as an intermittent failure on lab but runs fine
on a local dual-core environment. I'll debug this tomorrow morning.
* o.j.c.pojo - Ben, any updates on your integrations? I understand
you're on-site this 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
20 years, 1 month
RE: [jbosscache-dev] jboss-minimal.jar
by Brian Stansberry
Re: moving these classes to common-core, see
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90520
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> It probably will be when this new jar is created.
>
>> Couldn't that class be moved into the new common.jar that has been
>> discussed on the core recently ?
>>
>> Manik Surtani wrote:
>>> Whoops, no, it is needed for MarshalledValueOutputStreams --
>>> 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 7 Sep 2006, at 15:47, Manik Surtani wrote:
>>>
>>>> Ok, another jar gone. :-)
>>>> --
>>>> 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 7 Sep 2006, at 15:23, Brian Stansberry wrote:
>>>>
>>>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> Am I correct to assume that the only reason we ship JBC with
>>>>>> jboss- minimal.jar is so we have access to
>>>>>> org.jboss.logging.XLevel? And the purpose of logging.XLevel is
>>>>>> to give us TRACE level logging?
>>>>>>
>>>>>
>>>>> My gut instinct tells me it wasn't the original reason, but it
>>>>> looks like that's all that's left :)
>>>>>
>>>>> At least in 1.2.13 log4j now has its own TRACE level, and jdk
>>>>> logging has "FINE, FINER, FINEST" of which I'm sure
>>>>> commons-logging maps at least one or two to trace(). So I don't
>>>>> think it's worth it to ship the jar just for that; just ship the
>>>>> latest log4j (we're shipping 1.2.8).
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> --
>> Bela Ban
>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division of
>> Red Hat
>>
>
> _______________________________________________
> 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
20 years, 1 month
RE: [jbosscache-dev] storeState/loadState moved to AbstractCacheLoader
by Vladimir Blagojevic
Yes lets leave them there.
This is actually a prime example for what Joshua Bloch calls "combining
the virtues of interfaces and abstract classes by providing skeletal
implementation class to go with each nontrivial interface that you
export".
You don't have to go further than java collections library to see
example of this principle exploited to the maximum.
Vladimir
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Wednesday, September 13, 2006 5:58 AM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] storeState/loadState moved to
> AbstractCacheLoader
>
> Looks good.
>
> So we're still leaving store/load state methods in the cache
> loader interface? I suppose this is ok, as people may
> implement more efficient or specific versions of these rather
> than forcing the repeated use of put/get.
20 years, 1 month
