RE: [jbosscache-dev] jboss-minimal.jar
by Brian Stansberry
F?YI there is a task to move the org.jboss.invocation code into Remoting
(http://jira.jboss.com/jira/browse/JBREM-385). Not sure if that's meant
to include the MarshalledValue stuff. Putting it in common seems more
useful, as adding a dependency on a remoting jar would suck.
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
17 years, 7 months
RE: [jbosscache-dev] jboss-minimal.jar
by Brian Stansberry
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).
17 years, 7 months
RE: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
by Ben Wang
The problem of creating a direct cache instance is then I need to provide extra mbean defition for the Cache stats. User of PC still expects to see the replication configuration and stats, e.g. By obtaining the Cache from a Mbea/bean service, it will have those aspects automatically.
Of course, direct instance access (getCache()) is not what JMX advocates but I guess that will have to do here.
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Thursday, September 07, 2006 9:35 PM
To: Ben Wang
Cc: Bela Ban; jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
Is that how you'd like PojoCache to work? I would have thought in the case of PojoCache, it creates an instance of Cache first and then uses it, rather than using one registered in a JMX server.
In any case, if you would prefer to get it off JMX, CacheMBean could have a getCache() method that returns the Cache instance.
--
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 14:25, Ben Wang wrote:
> BTW, this JMX discussion also has impact on PojoCache as I am using
> Cache as a delegate now. Besides the Cache management attributes, I'd
> like to expose parts of PojoCache attributes as well. So I'd imagine
> that PojoCache should look for the Cache bean service when configured
> under AS, e.g. How does everyone see it?
>
> -Ben
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Thursday, September 07, 2006 6:36 PM
> To: Bela Ban
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
>
> Can't you register model MBeans programatically rather than via XML?
>
> Basically what I am thinking is an MBeanRegistrar class that inspects
> your interceptor stack, and has a hardcoded list of reflect.Methods to
> expose for each known interceptor type. Sure, it means one clunky
> class that does all of this but is this better than a dozen *MBean
> interfaces?
>
> 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 6 Sep 2006, at 22:30, Bela Ban wrote:
>
>> I already use model MBeans to expose certain JGroups services, e.g.
>> GossipRouter and Multiplexer. It geta bit unwieldy though, with all
>> the verbose XML... How do you suppose to expose interceptors ? I
>> think the big problem is that we need to dynamically expose
>> (=register) them at stack startup time ?
>>
>> Manik Surtani wrote:
>>> Hi guys.
>>>
>>> Rather than wrestle with MBean interfaces and also add clutter to
>>> the various interfaces we have - and also to support future exposure
>>> of interceptors, etc. to JMX, what do you think of using Model
>>> MBeans instead of Standard MBeans?
>>>
>>> http://java.sun.com/j2se/1.5.0/docs/api/javax/management/
>>> modelmbean/package-summary.html
>>>
>>> Now I'm no JMX expert and I may be talking nonsense here so feel
>>> free to tear this apart. Brian, how would something like this work
>>> for you since AS clustering gets cache references from JMX?
>>> Do we still need to extend ServiceMBean in AS5?
>>>
>>> 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
17 years, 7 months
jboss-minimal.jar
by Manik Surtani
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?
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
RE: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
by Ben Wang
BTW, this JMX discussion also has impact on PojoCache as I am using Cache as a delegate now. Besides the Cache management attributes, I'd like to expose parts of PojoCache attributes as well. So I'd imagine that PojoCache should look for the Cache bean service when configured under AS, e.g. How does everyone see it?
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, September 07, 2006 6:36 PM
To: Bela Ban
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
Can't you register model MBeans programatically rather than via XML?
Basically what I am thinking is an MBeanRegistrar class that inspects your interceptor stack, and has a hardcoded list of reflect.Methods to expose for each known interceptor type. Sure, it means one clunky class that does all of this but is this better than a dozen *MBean interfaces?
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 6 Sep 2006, at 22:30, Bela Ban wrote:
> I already use model MBeans to expose certain JGroups services, e.g.
> GossipRouter and Multiplexer. It geta bit unwieldy though, with all
> the verbose XML... How do you suppose to expose interceptors ? I
> think the big problem is that we need to dynamically expose
> (=register) them at stack startup time ?
>
> Manik Surtani wrote:
>> Hi guys.
>>
>> Rather than wrestle with MBean interfaces and also add clutter to
>> the various interfaces we have - and also to support future
>> exposure of interceptors, etc. to JMX, what do you think of using
>> Model MBeans instead of Standard MBeans?
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/javax/management/
>> modelmbean/package-summary.html
>>
>> Now I'm no JMX expert and I may be talking nonsense here so feel
>> free to tear this apart. Brian, how would something like this
>> work for you since AS clustering gets cache references from JMX?
>> Do we still need to extend ServiceMBean in AS5?
>>
>> 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
17 years, 7 months
JMX and MBeans in JBoss Cache 2.0.0
by Manik Surtani
Hi guys.
Rather than wrestle with MBean interfaces and also add clutter to the
various interfaces we have - and also to support future exposure of
interceptors, etc. to JMX, what do you think of using Model MBeans
instead of Standard MBeans?
http://java.sun.com/j2se/1.5.0/docs/api/javax/management/modelmbean/
package-summary.html
Now I'm no JMX expert and I may be talking nonsense here so feel free
to tear this apart. Brian, how would something like this work for
you since AS clustering gets cache references from JMX? Do we still
need to extend ServiceMBean in AS5?
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
RE: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hi guys.
>
> Rather than wrestle with MBean interfaces and also add
> clutter to the various interfaces we have - and also to
> support future exposure of interceptors, etc. to JMX, what do
> you think of using Model MBeans instead of Standard MBeans?
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/management/modelmbean/
> package-summary.html
That would be nice. Don't know if there will be any issue with the
properties that take a DOM Element.
>
> Now I'm no JMX expert and I may be talking nonsense here so
> feel free to tear this apart. Brian, how would something
> like this work for you since AS clustering gets cache
> references from JMX? Do we still need to extend ServiceMBean in AS5?
AS 5 services should be able to handle injection of pojos, so a cache
instance won't even need to be an MBean. I'll be dealing with the cache
via the Cache interface. The cache should just expose create(),
start(), stop(), destroy(). Of course we want it to be an MBean for
management purposes, but it doesn't have to be to be used by things like
session replication.
Also, even for the 1.x series for integration in 4.0.x there's no
requirement to extend ServiceMBeanSupport. Pretend for illustration we
wanted a 1.5.0. It would have to be a valid mbean and implement the 4
lifecycle methods, but implementing ServiceMBean or extending
ServiceMBeanSupport is not required.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
17 years, 7 months
RE: [jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0
by Brian Stansberry
Manik Surtani wrote:
>> Brian Stansberry wrote:
>>>
>>> Now I'm no JMX expert and I may be talking nonsense here so feel
>>> free to tear this apart. Brian, how would something like this work
>>> for you since AS clustering gets cache references from JMX? Do we
>>> still need to extend ServiceMBean in AS5?
>>
>> AS 5 services should be able to handle injection of pojos, so a cache
>> instance won't even need to be an MBean. I'll be dealing with the
>> cache via the Cache interface. The cache should just expose
>> create(), start(), stop(), destroy(). Of course we want it to be an
>> MBean for management purposes, but it doesn't have to be to be used
>> by things like session replication.
>>
>
> So is is just those 4 that we want to expose via JMX then?
> Ok, here is what I propose we expose via JMX:
>
> 1) lifecycle, as mentioned above.
> 2) API to get a List<ObjectName> of bound interceptor MBeans (is this
> necessary/useful?) 3) API to get Configuration
> 4) API to dump cache contents/printLockInfo()
> 5) API to get a hold of the Cache interface, and using this
> people have direct access to the cache rather than directly
> exposing all of the cache methods via JMX.
A difficulty with a limited JMX interface that exposes complex objects
like Cache and Configuration is you have to be in the same JVM to make
use of the complex objects.
1) No manipulation via a browser (aka jmx-console and web-console).
2) No manipulation via RMIAdaptor (remote interface to JMX server.)
3) Don't know how the ON guys deal with the cache -- probably through
RMIAdaptor.
If Configuration is serializable it can be accessed in a read-only way
through RMIAdaptor. But are there any config attributes that should be
changeable at runtime (e.g. timeouts, eviction policy configs)?
Not being able to access the Cache via RMIAdaptor is going to break some
AS unit tests for sure.
It is possible as a workaround to bind a proxy to the cache in JNDI and
access it that way.
I'm sympathetic to the desire to reduce the # of exposed methods
(particularly all the Configuration ones), but gotta point out the
problems :)
I think this is something that should be brought up on the user forum so
as many users as possible get a chance to comment on how they deal with
JBC via JMX.
17 years, 7 months
RE: [jbosscache-dev] Some new Cache usage questions
by Brian Stansberry
Somewhat off-topic..
If at webapp startup I do:
Node webappRoot =
cache.get(Fqn.fromString("/JSESSIONID/localhost/webapp1");
.. and then cache webappRoot
And then for various requests
Node session = webappRoot.getChild(sessionId);
return session.get(VERSION_ID);
Is that going to have any significant efficiency over simply doing this
for each request:
return cache.get("/JSESSIONID/localhost/webapp1/" + sessionId ,
VERSION_ID);
Let's disregard efficiencies related to constructing Fqn objects; assume
in real code that's highly optimized and not a big deal.
If the Node is just a wrapper around the cache that calls back into
TreeCache, that would imply that the former case will internally just
boil down to the latter case. So, the call will still walk the tree
from the root; it won't gain any efficiency because it can start at
"/JSESSIONID/localhost/webapp1". I'd think it would have to start at
the root, otherwise it can't acquire the necessary read locks.
Manik Surtani wrote:
> Basically just Hibernate - where in a given Hibernate session
> where data of a particular type is accessed, the node for
> that type can be cached and it's direct children queried
> without the need to find the node repeatedly. I guess it
> makes sense in this use case where the parent node will not
> (often) be removed from the tree.
>
>> TBH, this thread has lost me a bit. My expectation was for session
>> replication I'd as much as possible just use Cache.get(Fqn, Object)
>> Cache.put(Fqn, Object, Object), Cache.remove(Fqn, Object). I'm kind
>> of a simple-minded guy. :)
>>
>> So, I'm lost as to what the situation is where we'd be recommending
>> caching nodes. If it's a common situation where lot's of people will
>> blindly do it, that's a problem. If it's some specialized situation
>> where a sophisticated program can understand to use a try/catch
>> block, it's no big deal.
>>
>> It might be nice if the CacheException were a specialized subclass
>> that could be specifically caught.
>>
>> Manik Surtani wrote:
>>> A Node is still just a wrapper. Every time you try and do anything
>>> with it, calls are passed thru the interceptor stack to the
>>> TreeCache object.
>>>
>>> If a Node no longer exists, a CacheException will be thrown.
>>>
>>> Do we foresee this as a problem, and should we not be recommending
>>> caching Nodes?
>>>
>>>> Isn't caching a Node dangerous, as you have no way of knowing it
>>>> hasn't been removed from the tree? Unless you add a CacheListener
>>>> just for that.
>>>>
>>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>>> Use Cache for cache-wide operations like getRegion(), etc.
>>>>>
>>>>> Use Node to manipulate data in the node, retrieve child nodes,
>>>>> etc. This way refs to Nodes - buckets of data storage - can be
>>>>> cached since it is these that would be most frequently used.
>>>>>
>>>>>> It does. But then, does it mean I need to keep both the reference
>>>>>> for Cache and "parent" Node at the same time? Although Cache is a
>>>>>> wrapper, it does have some additional APIs like evict and also
>>>>>> getRegion() that doesn't exist in Node. Or what's your
>>>>>> recommendation?
>>>>>>
>>>>>> Actually, currently I am keeping the CacheSPI reference (and also
>>>>>> possibly NodeSPI in the future when it has life of its own)
>>>>>> within my code. Keeping the Node reference doesn't seem to make
>>>>>> much sense to me, although this can be just a pattern for the
>>>>>> customed cache provider (e.g., PojoCache).
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Manik Surtani [mailto:manik@jboss.org]
>>>>>> Sent: Tuesday, September 05, 2006 12:10 AM
>>>>>> To: Ben Wang
>>>>>> Cc: Bela Ban; jbosscache-dev(a)lists.jboss.org
>>>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions
>>>>>>
>>>>>>
>>>>>> On 4 Sep 2006, at 16:58, Ben Wang wrote:
>>>>>>
>>>>>>> 1. I suspect people using JBC for session management purpose
>>>>>>> won't store the Node ref but the Cache instead. Brian can say
>>>>>>> better but for example of the http session, unless you store the
>>>>>>> root Node, otherwise caching the children Node is not that
>>>>>>> useful.
>>>>>>
>>>>>> Node jSessionNode = Cache.getChild(Fqn.fromString("/
>>>>>> JSESSIONID")); // this can be cached... Node sessionNode =
>>>>>> jSessionNode.getChild(Fqn.fromString (sessionId)); // this can
>>>>>> be retrieved every time...
>>>>>>
>>>>>> Does this help in any way?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2. ic. Do we have explicit contract for Cache to be "root" Node
>>>>>>> only? I mean, even getRoot() is just a self pointer, it still
>>>>>>> serves the purpose, IMO.
>>>>>>
>>>>>> From the javadocs: "The cache is essentially a wrapper around
>>>>>> the default root Node."
>>>>>>
>>>>>>
>>>>> http://labs.jboss.com/file-access/default/members/jbosscache/
>>>>> freezone/
>>>>>> docs/Habanero/api/org/jboss/cache/Cache.html
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> -Ben
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Manik Surtani [mailto:manik@jboss.org]
>>>>>>> Sent: Monday, September 04, 2006 7:06 PM
>>>>>>> To: Ben Wang
>>>>>>> Cc: Bela Ban; jbosscache-dev(a)lists.jboss.org
>>>>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions
>>>>>>>
>>>>>>> Not in your case, no. But many other use cases will be able to
>>>>>>> cache a node and use it directly.
>>>>>>>
>>>>>>> I too would rather keep the API clean in this regard. Also,
>>>>>>> calling cache.getRoot() is redundant since the Cache interface
>>>>>>> is a wrapper around the root Node. In fact, I even think we
>>>>>>> should get rid of the getRoot() method.
>>>>>>>
>>>>>>> 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 1 Sep 2006, at 15:49, Ben Wang wrote:
>>>>>>>
>>>>>>>> Thing is I only do put to specific fqn once. So caching it
>>>>>>>> doesn't buy you anything.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Bela Ban
>>>>>>>> Sent: Friday, September 01, 2006 10:22 PM
>>>>>>>> To: Ben Wang
>>>>>>>> Cc: jbosscache-dev(a)lists.jboss.org
>>>>>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions
>>>>>>>>
>>>>>>>> My 2 cents: I'd rather keep the API clean, at the expense of
>>>>>>>> folks potentially writing wrapping code (like Ben).
>>>>>>>>
>>>>>>>> Your code samples look a bit weird:
>>>>>>>> #1
>>>>>>>> Why do you always get the child ? Can't you get the node and
>>>>>>>> cache it, e.g. Node n=cache.getRoot().getChild(fqn);
>>>>>>>> n.containsKey(PojoInstance.KEY)
>>>>>>>>
>>>>>>>> #2
>>>>>>>> Same as for #1: you don't need to call cache.getRoot().getChild
>>>>>>>> (fqn) all the time, for example in a loop, simply cache it
>>>>>>>>
>>>>>>>>
>>>>>>>> Ben Wang wrote:
>>>>>>>>> Manik,
>>>>>>>>>
>>>>>>>>> While trying to use the new API in PojoCache, I have found
>>>>>>>>> that I need to:
>>>>>>>>>
>>>>>>>>> 1. To check if a attribute exist, I need to do:
>>>>>>>>> cache_.getRoot().getChild(fqn_).getData().values().contains
>>>>>>>>> (PojoInstance.KEY)
>>>>>>>>>
>>>>>>>>> 2. And then, I need to do a lot of cache_.getRoot().getChild
>>>>>>>>> (fqn).put(map)
>>>>>>>>>
>>>>>>>>> So looks like I need to write a wrapper layer just to provide
>>>>>>>>> straight api for:
>>>>>>>>>
>>>>>>>>> Cache_.exists(fqn, key)
>>>>>>>>> And
>>>>>>>>> Cache_.put(fqn, map)
>>>>>>>>>
>>>>>>>>> If this is rare case, then I will bite the bullet. But if it
>>>>>>>>> is a common one, then that really begs the question whether we
>>>>>>>>> should provide additional apis or not?
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 7 months
State transfer error handling
by Vladimir Blagojevic
Hi,
As you know we now deal with streams in cache loaders. Since we have to
have an error handling mechanism that supports both streaming and byte
based transfers we cannot rely on buffer marking and resets to do state
transfer error handling anymore. We have to somehow indicate in stream
that an error occurred while writing data to stream.
Are we suppose to follow all or nothing approach when it comes to state
transfer? If we write out an error marker to the stream while writing
data and if reader encounters an error marker should we cleanup any
previous partial state that has already been read and integrated?
Let me know.
Vladimir
17 years, 7 months
