RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
I made TcpCacheLoader test pass but tcpcacheloader will not propagate
load/store. This was the case even before I made the cacheloader change.
Similar situation is with rpc and rmi loaders and we have to figure out
what to do there. Remaining items are:
- make bdje cacheloader compatible with streaming format
- write tests to confirm cacheloader interoperability (I am working on
this)
It would be great if someone familiar with bdjecacheloader can make it
compatible with streaming format.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Monday, September 11, 2006 12:00 PM
> 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
>
19 years
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Brian Stansberry
I'm not talking about an in-memory cache, but rather a remote one. But
I think I get what you mean. So, the cache loader gets a storeState()
call. Instead of
1) making one or more remove() calls to Cache 2 (the one it's delegating
to).
2) making a bunch of put() calls to Cache 2.
it would:
1) Create a bunch of remove Modifications and add them to a list
2) Create a bunch of put Modifications and add them to the list
3) Call CacheLoader.prepare(), passing in a GTX (from where?) and the
Modification list
Bela Ban wrote:
> Why not ? If we're only talking about an in-memory cache (no
> persistent cache loader at the far side), then transactions
> are passed to the cache in prepare() and commit()/rollback().
> Distributed transaction managers wouldn't help here IMO.
>
> Brian Stansberry wrote:
>> A different problem is that all the remove() and put() calls won't be
>> transactional on the far cache unless you're able to use a
>> distributed transaction manager.
19 years
RE: Logging jars
by Brian Stansberry
Manik Surtani wrote:
> 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?
+1.
19 years
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Brian Stansberry
A different problem is that all the remove() and put() calls won't be
transactional on the far cache unless you're able to use a distributed
transaction manager.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Thought about it a bit more, and I don't think it has that problem.
>
> If the remote cache is being used as a cacheloader, it should
> have no existence other than for that purpose. So, a store
> call should feel free to completely replace the subtree being stored.
>
> Therefore, the first step of the state transfer store should
> be to recursively remove all nodes for the given subtree in
> the remote cache.
> Thereafter there are no problems with leftover data.
>
> Vladimir Blagojevic wrote:
>> This approach would be a very nice and generic solution but as you
>> point it has a problem with integration/clearing of nodes.
>>
>> Looks like we have to do something along the lines that Manik
>> suggested. I'll assign that task to myself.
>>
>>> -----Original Message-----
>>> From: Brian Stansberry
>>> Sent: Monday, September 11, 2006 12:35 PM
>>> To: Vladimir Blagojevic; Manik Surtani;
>>> jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] JBoss
>>> Cache 2.0.0.ALPHA status
>>>
>>> Vladimir Blagojevic wrote:
>>>> I made TcpCacheLoader test pass but tcpcacheloader will not
>>>> propagate load/store. This was the case even before I made the
>>>> cacheloader change. Similar situation is with rpc and rmi loaders
>>>> and we have to figure out what to do there.
>>>
>>> In the case of store, is this a matter of reading out the NodeData
>>> objects and invoking a put(Fqn, Map) on the remote cache for each
>>> one? For load, a bunch of recursive get(Fqn) calls to create the
>>> NodeData? (I'm skipping any subtleties of the 2.0 API here.)
>>>
>>> A problem with the put(Fqn, Map) approach is that call integrates
>>> the passed Map into the target node, rather than replacing the map
>>> contents. So you could be left with stale key/value pairs in the
>>> far cache.
>
>
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> _______________________________________________
> 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
19 years
Re: Logging jars
by Manik Surtani
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
19 years
JBoss Cache 2.0.0.ALPHA status
by Manik Surtani
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
19 years
RE: [jbosscache-dev] o.j.c.statetransfer.VersionedTestBase
by Brian Stansberry
At line 297, it should be
cache2.getRegion(A).activate(); not just cache2.getRegion(A);
Sorry, looks like I broke that when changing to the 2.0 API. I can
check in the fix, or if you've got other changes to the file, you go
ahead.
- Brian
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> All,
>
> Any idea why VersionedTestBase.testPartialStateTferWithClassLoader()
> is implemented the way it is?
>
> Line 293 has:
>
> assertNull("/a/b not transferred to loader", loader.get(A_B));
>
> and soon after that (no more mods to the caches except some
> assertions) on line 302:
>
> assertEquals("Correct state from loader for /a/b",
> ben.toString(), loader.get(A_B).get("person").toString());
>
> This basically throws an NPE on loader.get(A_B).get("person")
> but this NPE is *expected*, based on the assertion before...
> ? Am I missing something here?
>
> Cheers,
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Brian Stansberry
Thought about it a bit more, and I don't think it has that problem.
If the remote cache is being used as a cacheloader, it should have no
existence other than for that purpose. So, a store call should feel free
to completely replace the subtree being stored.
Therefore, the first step of the state transfer store should be to
recursively remove all nodes for the given subtree in the remote cache.
Thereafter there are no problems with leftover data.
Vladimir Blagojevic wrote:
> This approach would be a very nice and generic solution but
> as you point it has a problem with integration/clearing of nodes.
>
> Looks like we have to do something along the lines that Manik
> suggested. I'll assign that task to myself.
>
>> -----Original Message-----
>> From: Brian Stansberry
>> Sent: Monday, September 11, 2006 12:35 PM
>> To: Vladimir Blagojevic; Manik Surtani;
>> jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] JBoss
>> Cache 2.0.0.ALPHA status
>>
>> Vladimir Blagojevic wrote:
>>> I made TcpCacheLoader test pass but tcpcacheloader will not
>>> propagate load/store. This was the case even before I made the
>>> cacheloader change. Similar situation is with rpc and rmi loaders
>>> and we have to figure out what to do there.
>>
>> In the case of store, is this a matter of reading out the NodeData
>> objects and invoking a put(Fqn, Map) on the remote cache for each
>> one? For load, a bunch of recursive get(Fqn) calls to create the
>> NodeData? (I'm skipping any subtleties of the 2.0 API here.)
>>
>> A problem with the put(Fqn, Map) approach is that call integrates the
>> passed Map into the target node, rather than replacing the map
>> contents. So you could be left with stale key/value pairs in the far
>> cache.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years
RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
by Vladimir Blagojevic
This approach would be a very nice and generic solution but as
you point it has a problem with integration/clearing of nodes.
Looks like we have to do something along the lines that Manik
suggested. I'll assign that task to myself.
> -----Original Message-----
> From: Brian Stansberry
> Sent: Monday, September 11, 2006 12:35 PM
> To: Vladimir Blagojevic; Manik Surtani; jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
> Vladimir Blagojevic wrote:
> > I made TcpCacheLoader test pass but tcpcacheloader will not
> propagate
> > load/store. This was the case even before I made the cacheloader
> > change.
> > Similar situation is with rpc and rmi loaders and we have to figure
> > out what to do there.
>
> In the case of store, is this a matter of reading out the
> NodeData objects and invoking a put(Fqn, Map) on the remote
> cache for each one? For load, a bunch of recursive get(Fqn)
> calls to create the NodeData? (I'm skipping any subtleties
> of the 2.0 API here.)
>
> A problem with the put(Fqn, Map) approach is that call
> integrates the passed Map into the target node, rather than
> replacing the map contents. So you could be left with stale
> key/value pairs in the far cache.
>
>
19 years