RE: Fundamental problem with pessimistic locking
by Brian Stansberry
Hmm; thinking out loud....
If you're not doing lots of adds/removes to the level below root, it's
not a big cost, right?
And if you are doing lots of adds/removes at that level, it's probably
important to have the correct locking behavior.
So, seems OK to me.
________________________________
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Tuesday, November 28, 2006 4:58 PM
To: Ben Wang; Bela Ban; Brian Stansberry; Vladimir Blagojevic;
Galder Zamarreno; jbosscache-dev(a)lists.jboss.org
Subject: Re: Fundamental problem with pessimistic locking
So we still haven't discussed my biggest concern here, which is
item 5) below in the list of implications. Is this performance penalty
and potential for deadlocks small enough a price to pay for the
correctness of concurrent access on the root node? What do people
think?
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, November 27, 2006 7:19 PM
To: Manik Surtani
Cc: Bela Ban; Ben Wang; Brian Stansberry; Vladimir
Blagojevic; Galder Zamarreno
Subject: Re: Fundamental problem with pessimistic
locking
Ok, this seems to work, making things a lot more
'correct'. But before I roll this into an official release and start
making changes en-masse, porting this to 1.4.x and 2.0.0, I'd like to
step back and think about whether this is what we really want. Here is
what I've effectively done with 1.3.0.SP4, all related to pessimistic
locking only:
a) Added a mechanism for not removing nodes when
remove() is called, and instead storing them in a map which can be
referenced by concurrent threads and locks attempted. (Mutated version
of Brian's original fix to JBCACHE-871)
b) When locking nodes in PLI.lock(), added a mechanism
to obtain a WL on a node if the next node after it needs to be created
or removed. (JBCACHE-875)
c) Modified PLI.lock() to start with Fqn.ROOT rather
than Fqn.get(0), which applies the same cache-wide locking behaviour to
the root as well. Prior to this, the root never was locked for
anything.
The implications of these, for the sake of accuracy and
correctness, are possibly:
1) Performance impact on inspecting nodes in b) to
decide on whether WLs are needed
2) Memory impact on maintaining a map of removed nodes
in a)
3) Reduced concurrency due to overall stronger locks in
b)
4) Much reduced concurrency because of the locking in
c)
5) Potential of more deadlocks/timeouts because of 3)
and 4) above.
Of the above, 5) manifests itself in a few unit tests
that have now started to fail (TxCacheLoaderTest, some state transfer
tests, etc.). Simple example, taken from one of the failing tests,
leads to a deadlock:
1: mgr.begin();
2: Transaction tx=mgr.getTransaction();
3: cache1.put("/one/two/three", "key1", "val1");
4: assertNull(cache2.get("/one/two/three", "key1"));
5: tx.commit();
Line 3 obtains a WL on "/" on cache1, for GTX 1
Line 4 obtains a WL on "/" on cache2, for GTX 2
Line 5, on replication, tries to get a WL on "/" on
cache2, for GTX 1
Both GTXs relate to the same TX since they are in the
same thread. Boom, deadlock.
One thing here though, in my opinion, another bug in the
original PLI:
When doing a get on a node that doesn't exist,
intermediate nodes are created. E.g., cache2.get("/one/two/three",
"key1") actually ends up creating /one/two/three first, and after the
JBCACHE-875 fix, /, /one and /one/two will be WL'd for a get() on a
nonexistent node!! Shouldn't the loop just be short-circuited such that
at any point, if the next node does not exist and the lock_type
requested is READ, just return a null? Saves us a whole bunch of
unnecessary WL's ...
Sorry about the long and rambling email. Thoughts and
opinions?
--
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 Nov 2006, at 10:16, Manik Surtani wrote:
Ok, take away the crap about it being a bug in
the util.concurrent code. It's a bug in JBC, specifically on line 75 in
TreeCache.java:
protected DataNode root =
NodeFactory.getInstance().createDataNode(NodeFactory.NODE_TYPE_TREENODE,
SEPARATOR, Fqn.fromString(SEPARATOR), null, null, this);
:-) The root node is initialised when new
TreeCache() is called, well before isolation levels, etc. are set, which
causes the root node to be created with isolation level of NONE. Hence
the insane behaviour when trying to content for write locks on the root
node.
Just fixed this, running a bunch of regressions
now.
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 26 Nov 2006, at 19:04, Bela Ban wrote:
Forwarding to the entire group
Manik Surtani wrote:
Ok, boiled it down to a contention issue
on locking Fqn.ROOT, which prior to JBCACHE-875, was never locked -
either for reading or writing. (I do this by changing the loop in the
lock() method in PLI to first consider the root before the individual
Fqn elements). (This problem is also apparent in
o.j.c.transaction.DeadlockTest on a multi-cpu box).
2006-11-26 14:58:09,566 DEBUG [Node]
(Thread-2) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:2,
lock=<unlocked>
<snip>
2006-11-26 14:58:09,572 DEBUG [Node]
(Thread-3) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:3,
lock=<unlocked>
<snip>
2006-11-26 14:58:09,576 DEBUG [Node]
(Thread-2) acquired WL: fqn=/, caller=GlobalTransaction:<null>:2,
lock=write owner=GlobalTransaction:<null>:2
<snip>
2006-11-26 14:58:09,581 INFO
[TxInterceptor] (Thread-3) There was a problem handling this request
java.lang.IllegalStateException: there
is already a writer holding the lock: GlobalTransaction:<null>:2 and
caller is GlobalTransaction:<null>:3
at
org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:101)
at
org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:187
)
at
org.jboss.cache.Node.acquireWriteLock(Node.java:557)
at
org.jboss.cache.Node.acquire(Node.java:517)
< snip - lots>
2006-11-26 14:58:09,850 DEBUG [Node]
(Thread-2) created child: fqn=/, child_name=NODE
I can't understand why concurrent WL
acquisition in IdentityLock.acquireWriteLock() behaves correctly for all
nodes except the root node. As you can see in the log snippet above,
both Thread-2 and Thread-3 call IdentityLock.acquireWriteLock (line 178)
and get a 'true', and one of the threads cause an exception on line 187.
--
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 26 Nov 2006, at 13:54, Manik Surtani
wrote:
I didn't want to acquire the WL
immediately since it involved an additional test to check if the next
node in the fqn needed creation. But I went with that algorithm in the
end since the locks had problems with concurrent readers attempting to
upgrade to writers.
So most of the regressions pass, as well
as the new tests introduced, and I am very close to something working,
EXCEPT one very strange problem with the IdentityLock and
ConcurrentCreationDeadlockTest.testLocalCacheLoader2Modifications() -
get the latest on the 1.3.0 branch for this to make any sense. The
problem is between lines 178 and 187 of IdentityLock, in the
acquireWriteLock() method.
Attempting to get a hold of a write lock
returns true, but setting the writer throws an exception since another
writer exists. Odd that this happens since the calling thread should
have the semaphore by then, also odd that this only seems to happen in
this one test which is meant to test concurrency in the
CacheLoaderInterceptor.
I'm still investigating, but if you have
any ideas about how and why this may happen, I'd love to hear it ... :-)
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 24 Nov 2006, at 15:25, Bela Ban
wrote:
Manik Surtani wrote:
On 24 Nov 2006, at 14:44, Bela Ban
wrote:
The first one you mentioned can lead to
race conditions, depending on the order of whether the upgrade on b or
the creation/WL on c happens first. What I've implemented is more like:
1: Acquire RL on a
2: Acquire RL on b
3: Identify that we need to create c.
4: Upgrade RL on b to WL
5: *now* create c, and acquire WL on it.
So there is a possibility that step 4
may block until other readers on b release their locks, but no one else
could grab the WL since the current TX will have a RL.
I see. Why don't you acquire a WL on b
(step 2) *immediately* rather than going through the upgrade if you know
you have to acquire a WL later anyway ? You might still deadlock:
2: acquire RL on b
(in the meantime): some other TX
acquires a RL on b, possibly upgrades to WL
3: you want to acquire a WL on b and
block on the other TX's RL or WL
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
17 years, 5 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
by Brian Stansberry
+1. After I wrote the below I thought about the fact that it's the AS that adds the classloading complexity that exposes some issues. So the AS needs to be sure to exercise things, well above and beyond the basic requirements.
Still, it's important to realize that AFAICT the JBoss EJB3 layers add very little on top of what comes with Hibernate (including Hibernate EntityManager). So I want to be sure we don't get into a situation where EJB3 tests are substituting for tests in Hibernate (or JBC), because by the time the EJB3 tests get run on new Hibernate/JBC releases, it's likely to be near the end of their release cycle.
Manik Surtani wrote:
> +1 on all these points, including a compat matrix that Galder
> suggested.
>
> Perhaps the binding 'glue' to this should be the AS, since
> moving forward (with AS5), we will have integration between
> the EJB3 entity beans and JBC. We will have more tests
> within the JBC suite to consider the entity bean use case,
> and I'm sure Hibernate will add more tests to their suite to
> deal with 2nd level caching vagaries specific to JBC, but I'd
> like to see some on the AS level (like we have with tomcat
> session clustering) which can act as a driver to integrate
> the 2 pieces.
>
> Thoughts?
>
>> My thoughts on this:
>>
>> 1) IMO the Hibernate use case for entity caching is really a standard
>> use case for JBC, and thus should be thoroughly simulated in the JBC
>> test suite. 2) In general, a component that integrates another
>> component should have basic tests of its usage of that component in
>> its own test suite. These tests need to be more thorough if there is
>> any non- trivial integration layer, which Hibernate certainly has on
>> top of JBC. Thus Hibernate should have tests of JBC as a 2nd level
>> cache that cover all aspects of its use. 3) Hibernate is a major JBC
>> consumer, akin to the AS. Thus, before a JBC release goes out (at
>> least a CR), a Hibernate release with which it is meant to integrate
>> should be identified. Part of the QA process for the JBC release
>> should be to run the Hibernate testsuite using the new JBC release.
>> Same as what we do for the AS. 4) Higher level services built on top
>> of Hibernate/EJB (e.g. EJB3) should follow the same principles with
>> respect to Hibernate as #2 above.
>>
>>
>> Galder Zamarreno wrote:
>>> +10 on JBC/Hibernate integration testing too, but whose
>>> responsibility +would be to deal with them and make sure that they
>>> work? Hibernate or +JBC developer's? Rather than splitting
>>> responsibility, I
>>> think it'd be
>>> +easier to have someone in charge of it who would lease with
>>> the rest of
>>> +Hibernate and JBC developers, but this is different topic
>>> already... +:-)
>>>
>>> I sent an email a month ago about the possibility of creating a
>>> Hibernate/JBC compatibility matrix but not a single person replied.
>>> These tests would give us the information we need for this.
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value
>>> http://www.redhat.com/promo/vendor/
>>>
>>> -----Original Message-----
>>> From: jbosscache-dev-bounces(a)lists.jboss.org
>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian
>>> Stansberry Sent: 17 November 2006 16:44
>>> To: Manik Surtani
>>> Cc: jbosscache-dev(a)lists.jboss.org
>>> Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the
>>> JBoss EJBContainer] - Problemwith order of entity cache operations
>>> withHibernate
>>>
>>> +10 on JBC/Hibernate integration testing.
>>>
>>> The EJB3 testsuite has one test in this area, which luckily
>>> uncovered the issue. Only uses the TM that's integrated in the AS;
>>> it was a lucky hit.
>>>
>>> There should be more EJB3 tests as well, but the primary place for
>>> it should be in Hibernate/JBC. E.g. this issue quite likely
>>> impacts non-EJB3 Hibernate as well.
>>>
>>> That's how we find such a thing. Anyone have any good thoughts on
>>> what to do about it? Perhaps Hibernate exposes something like JBC's
>>> OrderedSynchronizationHandler, which the JBC integration can use to
>>> insert it's synchronization at the correct point?
>>>
>>> Manik Surtani wrote:
>>>> Hmm, the *correct* approach to dealing with this would be to put
>>>> together a series of integration tests for JBoss Cache and
>>>> Hibernate, exercising such scenarios with different TMs, and making
>>>> sure these are run with every release of Hibernate and JBC. Either
>>>> that, or we assume the EJB3 test suite covers this, and I presume
>>>> this is how you uncovered this issue?
>>>>
>>>>
>>>>> FYI; just posted on the EJB3 forum.
>>>>>
>>>>> bstansberry(a)jboss.com wrote:
>>>>>> There appears to be a difference in behavior between JBossTM and
>>>>>> JBossTS that's leading to failures with JBoss Cache as the 2nd
>>>>>> level entity cache.
>>>>>>
>>>>>> JBC handles replication of transaction-scoped cache changes by
>>>>>> registering as a transaction Synchronization and replicating the
>>>>>> changes during the beforeCompletion() callback. This is failing
>>>>>> with JBossTS because the beforeCompletion() callback is being
>>>>>> executed *before* the Hibernate flush activity that updates the
>>>>>> cache. No activity at time of beforeCompletion() == no
>>>>>> replication of the tx's changes.
>>>>>>
>>>>>> 2006-11-16 23:48:41,250 TRACE
>>>>>> [org.jboss.cache.interceptors.TxInterceptor] Running
>>>>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
>>>>>> 2006-11-16 23:48:41,250 TRACE
>>>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up
>>>>>> transactional context. 2006-11-16 23:48:41,250 TRACE
>>>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
>>>>>> TransactionImple < ac, BasicAction:
>>>> -3f57ff9b:a5b:455d4cd6:10 status:
>>>>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1
>>>>>> 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] No
>>>>>> modifications in this tx. Skipping beforeCompletion()
>>>>>> 2006-11-16 23:48:41,250 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener]
>>>>>> processing flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>>>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>>>>> [org.hibernate.engine.Collections] Collection found:
>>>>>>
> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>>>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed:
>>>>>> 3 insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>>>>> 23:48:41,265 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed:
>>>>>> 1 (re)creations, 0 updates, 0 removals to 1 collections ...
>>>>>> followed by puts into the cache
>>>>>>
>>>>>> When I switched the AS back to using JBossTM, the problem went
>>>>>> away -- the Hibernate flush activity occurred first, and then the
>>>>>> beforeCompletion() call to JBC.
>>>>>>
>>>>>> I'm speculating that Hibernate is also using a Synchronization to
>>>>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>>>>> registered Synchronizations in a different order.
>>>>>>
>>>>>> At this point, replication of clustered EJB3 entities is
>>>>>> basically broken.
>>>>>>
>>>>>> View the original post :
>>>>>>
>>>>> http://www.jboss.com/index.html?
>>>>> module=bb&op=viewtopic&p=3986745#3986745
>>>>>>
>>>>>> Reply to the post :
17 years, 5 months
RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
by Galder Zamarreno
I have also been working on the QA entry to go along with this:
Q. Can I use <literal>TreeCache</literal> Marshalling in order to get around ClassCastExceptions happening when accessing data in the cache that has just been redeployed?
R. Yes, you can. Originally, <literal>TreeCache</literal> Marshalling was designed firstly, to provide improved performance over Java serialization and secondly, as a workaround for those replicated caches that upon state transfer did not have access to the classloaders defining the objects in the cache.
On each deployment, JBoss creates a new classloader per the top level deployment artifact, for example an EAR. You also have to bear in mind that a class in an application server is defined not only by the class name but also its classloader. So, assuming that the cache is not deployed as part of your deployment, you could deploy an application and put instances of
classes belonging to this deployment inside the cache. If you did a redeployment and try to do a get operation of the data previously put, this would result on a ClassCastException. This is because even though the class names are the same, the class definitions are not. The current classloader is different to the one when the classes were originally put.
By enabling marshalling, you can control the lifecycle of the data in the cache and if on undeployment, you inactivate the region and unregister the classloader that you'd have registered on deployment, you'd evict the data in the cache locally. That means that in the next deployment, the data won't be in the cache, therefore avoiding the problem.
Obviously, using marshalling to get around this problem is only recommended when you have some kind of persistence backing where the data survives, for example using CacheLoaders, or when JBossCache is used as a second level cache in a persistence framework.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 27 November 2006 12:55
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
I have been able to reproduce a similar behaviour without needing to have an integration test with AS. We don't currently have tests like this.
It assumes two classloaders, the default AppClassLoader (ClassLoader.getSystemClassLoader()) and another URL based one (parent is null, so that it's independent from the default, similar to redeployments where classloaders are siblings which don't know about each other) created in the unit test.
Once the URL one is created, I switch the context class loader to it and creates a new instance of org.jgroups.Global from jgroups.jar. I thought about creating a new instance of any other JBC class, but I can't assume that build has been executed and the ide class file location is not the same for everyone so couldn't assume that either.
Once the new instance is in the cache, I switch to the system class loader and attempt to do a get which results in a ClassCastException as expected.
The original test is pretty much the same as this, but with the added control over classloader registration and region inactivation.
Once I switch to the URL based classloader, I register it to the root. I create the new instance and do the put followed by inactivation of the region and unregistering of the class loader.
I then switch the context class loader to the old AppClassLoader and register it. I do a get operation for the data put earlier and returns null which is what is expected as the data referenced by the previous class loader does not exist any more. I end up inactivating and unregistering the class loader.
I have attached the UT so that you can have a look to it.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 24 November 2006 19:09
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] easing the path for clients togetaroundredeployment class loading issues in JBC
If you can recreate the CCE on redeployment I'd prefer it. Don't
worry about 1.4.1.CR1, it will probably be mid-week anyway.
--
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 24 Nov 2006, at 16:54, Galder Zamarreno wrote:
> The UT that I have is pretty simple. You start a local cache, set
> use marshalling and register Thread.currentThread
> ().getContextClassLoader().
>
> You put some data in the cache and then you inactivate the region
> and unregister the classloader.
>
> Further checks on whether the data entered exists returns false.
>
> Is this good enough? I thought about creating a test where I can
> reproduce the ClassCastException on redeployment but I'll need more
> time to create a UT like that.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 24 November 2006 17:11
> To: Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] easing the path for clients
> togetaroundredeployment class loading issues in JBC
>
> When are you planning to release 1.4.1.CR? I'm gonna try to do this
> over the weekend.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: Manik Surtani [mailto:msurtani@redhat.com]
> Sent: 17 November 2006 14:21
> To: Galder Zamarreno
> Cc: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] easing the path for clients to
> getaroundredeployment class loading issues in JBC
>
> Ok, Galder, if you don't mind, could you put together a unit test and
> an FAQ entry in the 1.4.x branch, so that this makes it in the next
> 1.4.1.CR release?
>
> Also raise a JIRA about this for 2.0.0.
>
> 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
>
>
> On 17 Nov 2006, at 11:56, Galder Zamarreno wrote:
>
>> +1
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>> promo/vendor/
>>
>> -----Original Message-----
>> From: Manik Surtani [mailto:msurtani@redhat.com]
>> Sent: 07 November 2006 10:01
>> To: Galder Zamarreno
>> Cc: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
>> Subject: Re: [jbosscache-dev] easing the path for clients to
>> getaroundredeployment class loading issues in JBC
>>
>> Hi,
>>
>> Interesting that enabling a marshaller even helps with non-replicated
>> cases where a marshaller is NOT needed! :-)
>>
>> I suspect this is emergent behaviour since enabling the marshaller
>> allows you to attach classloaders for regions (throws exceptions
>> otherwise). So the *intended* behaviour is for this to work with
>> replication only; if we want to make this a *feature* (and I suspect
>> we do) we should refactor and document accordingly.
>>
>> If we have a UT for this and know that this works, we could add a FAQ
>> for this for the 1.4.x series, and engineer it properly in 2.0.0.
>>
>> Thoughts?
>> --
>> 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 3 Nov 2006, at 13:05, Galder Zamarreno wrote:
>>
>>> In this specific case, it was a second level cache for EJB3 entity
>>> beans, so I guess there's not much of a problem in evicting on
>>> undeployment.
>>>
>>> This is a different use case to the one where you start JBC, state
>>> transfer occurs and you don't have all the classloaders.
>>>
>>> I guess another use for marshalling would be with isolated
>>> deployments, where JBC classloader is located in the default
>>> repository and u have several isolated applications populating that
>>> cache.
>>>
>>> However, in this particular case about 2nd level cache
>>> redeployment, do you think it's necessary to use marshalling? A
>>> simple evict everything on undeployment would be sufficient. What
>>> do you think?
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>>
>>> -----Original Message-----
>>> From: Brian Stansberry
>>> Sent: 02 November 2006 16:58
>>> To: Galder Zamarreno; 'jbosscache-dev(a)lists.jboss.org'
>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>> getaroundredeployment class loading issues in JBC
>>>
>>> Yeah, it works if it's OK that all the cached data was lost :-).
>>> With a replicated cache, the node going through redeploy evicts
>>> everything but can then recover it from another node. With local
>>> cache, it's evicted and gone. Actually, not technically evicted,
>>> just removed w/o going through the interceptor chain.
>>>
>>> If they want to keep the cached data, they'd need to store it in
>>> the cache as a byte[] or something and deserialize after redeploy.
>>> Or, use a non-passivating cache loader and recover from the cache
>>> loader. Or use a passivating cache loader and manually evict()
>>> each node before undeploying.
>>>
>>> Don't think I'll document this particular use, because calling
>>> inactivateRegion() as a shortcut for calling evict() is not really
>>> what the method's meant for. But I'm sure the docs in general on
>>> how to use this could be improved.
>>>
>>> Galder Zamarreno wrote:
>>>> I have just tried it with a local cache and it worked.
>>>>
>>>> One of the customers was using JBC 1.0, so the work was not in
>>>> vain :)
>>>>
>>>> It might be worth adding the redeployment case to the
>>>> documentation in the marshaller section.
>>>>
>>>> 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
>>>> Galder Zamarreno
>>>> Sent: 02 November 2006 16:31
>>>> To: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
>>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>>> getaroundredeployment class loading issues in JBC
>>>>
>>>> I did suggest this to Manik, but he told me that marshalling
>>>> would not work on local caches, but only in replicated ones.
>>>> I might have misunderstood him.
>>>>
>>>> The doc focuses on the state transfer issues when class
>>>> loaders are not still available.
>>>>
>>>> Galder Zamarreño
>>>> Sr. Software Maintenance Engineer
>>>> JBoss, a division of Red Hat
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Brian Stansberry
>>>> Sent: 02 November 2006 15:58
>>>> To: Galder Zamarreno; jbosscache-dev(a)lists.jboss.org
>>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>>> get aroundredeployment class loading issues in JBC
>>>>
>>>> There's already an API for this kind of use case. I'm going
>>>> to speak in 1.x terms here:
>>>>
>>>> // Config for cache startup
>>>> TreeCache.setUseRegionBasedMarshalling(true);
>>>> TreeCache.inactiveOnStartup(true); // suppresses initial
>>>> state transfer
>>>>
>>>> // Deploy phase -- app creates a region and registers it's
>>>> classloader TreeCache.registerClassloader(Fqn, ClassLoader);
>>>> // Then transfer the state for the region, since you've now
>>>> go the correct classloader TreeCache.activateRegion(Fqn);
>>>>
>>>> // Operate normallly
>>>>
>>>> // Undeploy phase -- deactivate the region, which evicts all nodes
>>>> TreeCache.inactivateRegion(Fqn)
>>>> // Don't leak a classloader ref
>>>> TreeCache.unregisterClassloader(Fqn);
>>>>
>>>> - Brian
>>>>
>>>> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>>>>> Hi,
>>>>>
>>>>> I have seen couple of people with the same issue in the past few
>>>>> weeks. I already had a chat with Manik but it was more about
>>>>> solving
>>>>> the problem at the time rather than thinking how we can make it
>>>>> easier for the customers to get around it.
>>>>>
>>>>> Applications which are redeployed and interact with the cache are
>>>>> quite likely to encounter class loading issues. They tend to enter
>>>>> data in the cache, they get redeployed, try accessing the data
>>>>> entered previously and you end up with a ClassCastException.
>>>>>
>>>>> For caches managed by Hibernate, this is not a problem cos
>>>>> Hibernate
>>>>> does the cleanup on undeployment, asking clients to close the
>>>>> session.
>>>>>
>>>>> In the rest of cases, clients have to iterate over evict() calls.
>>>>> This will be solved in JBC 2.0 with evictSubtree() method that can
>>>>> be recursive.
>>>>>
>>>>> However, clients still need to code an MBean which is part of the
>>>>> lifecycle of the deployment, and upon destroy, it calls
>>>>> evictSubtree().
>>>>>
>>>>> The cache configuration would have to depend on this MBean in case
>>>>> the cache deployment is done inside the client's application.
>>>>> Otherwise, we could assume that undeployment of JBC is quite
>>>>> likely
>>>>> due to AS undeployment in which case there's no need for cleanup.
>>>>>
>>>>> Have you got any ideas of anything else that could be done in
>>>>> JBC to
>>>>> help speed up this implementation and make it less of daunting
>>>>> task
>>>>> for the customer?
>>>>>
>>>>> I guess the main part is documenting all this.
>>>>>
>>>>> Galder Zamarreño
>>>>> Sr. Software Maintenance Engineer
>>>>> 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
17 years, 5 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
by Brian Stansberry
My thoughts on this:
1) IMO the Hibernate use case for entity caching is really a standard use case for JBC, and thus should be thoroughly simulated in the JBC test suite.
2) In general, a component that integrates another component should have basic tests of its usage of that component in its own test suite. These tests need to be more thorough if there is any non-trivial integration layer, which Hibernate certainly has on top of JBC. Thus Hibernate should have tests of JBC as a 2nd level cache that cover all aspects of its use.
3) Hibernate is a major JBC consumer, akin to the AS. Thus, before a JBC release goes out (at least a CR), a Hibernate release with which it is meant to integrate should be identified. Part of the QA process for the JBC release should be to run the Hibernate testsuite using the new JBC release. Same as what we do for the AS.
4) Higher level services built on top of Hibernate/EJB (e.g. EJB3) should follow the same principles with respect to Hibernate as #2 above.
Galder Zamarreno wrote:
> +10 on JBC/Hibernate integration testing too, but whose responsibility
> +would be to deal with them and make sure that they work?
> Hibernate or
> +JBC developer's? Rather than splitting responsibility, I
> think it'd be
> +easier to have someone in charge of it who would lease with
> the rest of
> +Hibernate and JBC developers, but this is different topic already...
> +:-)
>
> I sent an email a month ago about the possibility of creating
> a Hibernate/JBC compatibility matrix but not a single person
> replied. These tests would give us the information we need for this.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value
> http://www.redhat.com/promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Brian Stansberry
> Sent: 17 November 2006 16:44
> To: Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design
> of the JBoss EJBContainer] - Problemwith order of entity
> cache operations withHibernate
>
> +10 on JBC/Hibernate integration testing.
>
> The EJB3 testsuite has one test in this area, which luckily
> uncovered the issue. Only uses the TM that's integrated in
> the AS; it was a lucky hit.
>
> There should be more EJB3 tests as well, but the primary
> place for it should be in Hibernate/JBC. E.g. this issue
> quite likely impacts
> non-EJB3 Hibernate as well.
>
> That's how we find such a thing. Anyone have any good
> thoughts on what to do about it? Perhaps Hibernate exposes
> something like JBC's OrderedSynchronizationHandler, which the
> JBC integration can use to insert it's synchronization at the correct
> point?
>
> Manik Surtani wrote:
>> Hmm, the *correct* approach to dealing with this would be to put
>> together a series of integration tests for JBoss Cache and Hibernate,
>> exercising such scenarios with different TMs, and making sure these
>> are run with every release of Hibernate and JBC. Either that, or we
>> assume the EJB3 test suite covers this, and I presume this is how
>> you uncovered this issue?
>>
>>
>>> FYI; just posted on the EJB3 forum.
>>>
>>> bstansberry(a)jboss.com wrote:
>>>> There appears to be a difference in behavior between JBossTM and
>>>> JBossTS that's leading to failures with JBoss Cache as the 2nd
>>>> level entity cache.
>>>>
>>>> JBC handles replication of transaction-scoped cache changes by
>>>> registering as a transaction Synchronization and replicating the
>>>> changes during the beforeCompletion() callback. This is failing
>>>> with JBossTS because the beforeCompletion() callback is being
>>>> executed *before* the Hibernate flush activity that updates the
>>>> cache. No activity at time of beforeCompletion() == no
>>>> replication of the tx's changes.
>>>>
>>>> 2006-11-16 23:48:41,250 TRACE
>>>> [org.jboss.cache.interceptors.TxInterceptor] Running
>>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
>>>> 2006-11-16 23:48:41,250 TRACE
>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up
>>>> transactional context. 2006-11-16 23:48:41,250 TRACE
>>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
>>>> TransactionImple < ac, BasicAction:
>> -3f57ff9b:a5b:455d4cd6:10 status:
>>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
>>>> 23:48:41,250 TRACE
> [org.jboss.cache.interceptors.TxInterceptor] No
>>>> modifications in this tx. Skipping beforeCompletion() 2006-11-16
>>>> 23:48:41,250 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] processing
>>>> flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>>> [org.hibernate.engine.Collections] Collection found:
>>>> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
>>>> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>>> 23:48:41,265 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1
>>>> (re)creations, 0 updates, 0 removals to 1 collections ... followed
>>>> by puts into the cache
>>>>
>>>> When I switched the AS back to using JBossTM, the problem went away
>>>> -- the Hibernate flush activity occurred first, and then the
>>>> beforeCompletion() call to JBC.
>>>>
>>>> I'm speculating that Hibernate is also using a Synchronization to
>>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>>> registered Synchronizations in a different order.
>>>>
>>>> At this point, replication of clustered EJB3 entities is basically
>>>> broken.
>>>>
>>>> View the original post :
>>>>
>>> http://www.jboss.com/index.html?
>>> module=bb&op=viewtopic&p=3986745#3986745
>>>>
>>>> Reply to the post :
>>>>
>>> http://www.jboss.com/index.html?
>>> module=bb&op=posting&mode=reply&p=398674
>>> 5
>>>> _______________________________________________
>>>> jboss-dev-forums mailing list
>>>> jboss-dev-forums(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
>>>
>>> _______________________________________________
>>> 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
17 years, 5 months
RE: [jbosscache-dev] JBCACHE-867
by Galder Zamarreno
>> 5. Cache needs move(), not Node. The reason is clear if you see
>> NodeImpl.
>>
>Yes, this is one I have been toying with. What do others think?
Using move() does seem natural, you're in a node and want to move it and his children to other fqn.
The only downside I can see is people using it from the Cache interface and not realising that this is Node method which might leave them wondering which node you are moving...etc.
I guess a move(Node1, Node2, newFqn) might be easier to read, but this is a method that could well live in Node as it does right now, leaving space for other things in the Cache interface.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 20 November 2006 16:43
To: genman(a)noderunner.net
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBCACHE-867
On 20 Nov 2006, at 04:25, Elias Ross wrote:
>
>
> I finished most of getting rid of the TreeCacheProxyImpl
> references. It took
> more time than anticipated.
>
> All said, it was about 1800 lines of adds and 2000 lines of removes.
> TreeNode and DataNode are pretty empty. There's now a NodeSPI
> which might
> need some work, but it's pretty pleasant. I also refactored out a
> lot of
> lock stuff into something that hangs off of NodeSPI.
>
> Some tests may have been messed up (buddy replication and the move
> feature
> and probably some others) and I haven't had time to figure these
> complicated
> ones out. I hope this doesn't upset anybody. If somebody could
> help fix
> these, that would be great.
No this is fine, this was on the cards for me but you've saved me a
bit of work here. :-) Now just to make sure none of the
functionality's broken.
>
> I would like to suggest the following things:
> 1. Cache should not implement Node, it's confusing when reading an
> implementation of Cache
We toyed with this quite a bit and in the end we decided to go ahead
with it since it lets people use the Cache directly rather than to
get a hold of a Node first. In what ways do you feel this is confusing?
> 2. Node sould include useful methods of TreeNode, such as getChild
> (Object)
> and getName()
There is getChild(Fqn) - and I want to standardise on this. The Fqn
passed in is relative to the Node in question so you can have access
to direct children.
Similarly with getName(), I prefer getFqn().getLast() simply because
it cements the use of Fqns when it comes to identifying Nodes, and I
don't think adding a boatload of convenience methods helps the
interface very much.
> 3. Cache should have a getCacheSPI()
Again, -1. I had this in place initially (again as a temp measure)
and refactored this out. The purpose of the SPI is to give users
access to an 'advanced' API which would only be of value to people
implementing Cache Loaders, Cache Listeners or custom Interceptors.
Not for typical use of the cache. And as such, this interface should
only be injected into such Cache Loaders, Listeners and Interceptors.
> 4. CacheSPI should not extend Cache
In the case of Cache Loaders, Listeners and Interceptors, they would
need access to both interfaces. Don't want to pass in a Cache *and*
a CacheSPI, and don't want Cache.getCacheSPI() for the reasons
outlined above. :-)
> 5. Cache needs move(), not Node. The reason is clear if you see
> NodeImpl.
>
Yes, this is one I have been toying with. What do others think?
> In the current design, CacheSPI has to have all the methods of
> Cache. Why
> couldn't CacheSPI be written as a separate object? (It could, but
> then you
> would just have to delegate ...)
>
>
>
> ______________________________________________________________________
> ______________
> Sponsored Link
>
> Mortgage rates near 39yr lows.
> $510k for $1,698/mo. Calculate new payment!
> www.LowerMyBills.com/lre
> _______________________________________________
> 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
17 years, 5 months
Anycast: JBCACHE-813 & JGRP-338
by Manik Surtani
Bela/Vladimir:
Regarding broadcasting calls to a subset of members in a cluster, if
I were to callRemoteMethods() to N members ( where N > 1 and N < all
members) how does this behave, especially when using TCP or TCP_NIO?
I know that with UDP, a multicast is made and the members not on the
target list ignore the messages. Is this the same with TCP/TCP_NIO,
i.e., is the message broadcast to all members again and the members
not on the target list ignore the messages? (Hugely wasteful, and
hence the need for anycast).
In JBoss Cache 1.4.1, I've implemented JBCACHE-813 so a unicast is
used if the recipient list is 1 - a bit of a hack to work around this
inefficiency. But this in itself is not foolproof since, say using
Buddy Replication in a cluster of 30 servers and using 3 buddies per
node, we still end up unicasting the message to all 30 nodes only for
27 of them to ignore it.
We could hack in a config param - a unicast threshold (UT) - where if
N <= UT and N <= all members, we use a series of forced unicasts?
The drawback is that this only makes sense with TCP/TCP_NIO. Using
this with UDP will probably result in worse performance since a
single broadcast would be better.
Thoughts?
--
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, 5 months
RE: [jbosscache-dev] Perf tuning for JBoss Cache
by Galder Zamarreno
Pretty much all cache loaders except the delegating ones :)
+1 on FAQ
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 27 November 2006 20:11
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Perf tuning for JBoss Cache
On 27 Nov 2006, at 18:03, Galder Zamarreno wrote:
>
> Ok then, apply VAM to all cache loaders (or at least refactor it so
> that other CLs can be changed easily at a later stage) and provide
> bridging app that would get data from one and store in the other,
> in order to transform from 1.x marshalling to VAM in 2.0.
I wouldn't apply this to *all* cache loaders - just ones that
serialize data (I have a funny feeling this would be all cache
loaders though!)
I don't think we should provide a bridging app. Perhaps just write
an FAQ about it and let users implement it based on their app.
Chances are they would do this anyway.
17 years, 5 months
JBCACHE-880
by Manik Surtani
Hi Elias,
Have you discussed JBCACHE-880 on the forums yet? I don't see a link
to a forum thread on the task.
I'm not too excited by the implementation here, putting 'special'
values in a node's hashmap is always ugly and although we do it with
the UNITIALIZED marker, I'm not a fan of this. We should discuss
this a bit further on the forums, see if there is a better solution.
Also, I'd like to understand the use case a bit better as to why such
a mechanism is useful in a 'generic' implementation (I can see this
as a great custom policy, though)
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, 5 months
RE: [jbosscache-dev] Perf tuning for JBoss Cache
by Galder Zamarreno
> Write a 'bridge' app, which starts 2 instances of JBC (old and new -
> can these even run in the same VM together?) and yanks data out of
> one and into the other?
Hmmm, interesting, I was thinking more about bridging the cache loaders, but it might be simpler to do a bridge between JBC instances directly.
Ok then, apply VAM to all cache loaders (or at least refactor it so that other CLs can be changed easily at a later stage) and provide bridging app that would get data from one and store in the other, in order to transform from 1.x marshalling to VAM in 2.0.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 27 November 2006 18:46
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Perf tuning for JBoss Cache
On 27 Nov 2006, at 17:06, Galder Zamarreno wrote:
> Yeah, I was looking at using the VAM from TreeCache as well :-)
>
> There's only one downside to using VAM in the JDBCCacheLoader. Any
> data previously stored in the JDBCCacheLoader would not be
> compatible from this version onwards, or I guess they'd have to
> revert back to the old way.
I'm happy to break compat when moving to 2.0.0. This will happen in
so many other areas anyway.
>
> Afaik, we can switch jboss serialization on/off, but not VAM (which
> is used from JBossCache 2.0), can we? I guess we're moving up to
> 2.0 so this leap might be acceptable.
>
> Ok, so if we have customers that want to switch to 2.0 but they
> have loads of data already in the database, how could we ease the
> transformation of any data that they might have in the database?
Write a 'bridge' app, which starts 2 instances of JBC (old and new -
can these even run in the same VM together?) and yanks data out of
one and into the other?
>
> Any ideas?
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: 27 November 2006 17:55
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Perf tuning for JBoss Cache
>
>
> On 27 Nov 2006, at 09:47, Galder Zamarreno wrote:
>
>> I have updated it with a couple of JIRA.
>>
>> Are you guys happy with those? We had already talked about the
>> connection pooling stuff. Check the other one regarding
>> serialization in the JDBCCacheLoader.
>
> Yes,, you have a +1 from me already. Regarding the marshallers,
> could we use an instance of the VersionAwareMarshaller created in
> TreeCache? Just pass this instance to the JDBCCacheLoader (and any
> other cloaders that need to serialize objects, such as
> TcpRemoteCacheLoader) and use the VAM's object{To|From}ByteBuffer()
> methods. This way cloaders will be version-aware too, in the same
> way replication code is, and we'll have some degree of interop.
> (Sweet!)
>
> I'm adding a getMarshaller() method to CacheSPI for this purpose to
> cloaders have access to it.
>
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>> promo/vendor/
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
>> Sent: 21 November 2006 17:24
>> To: jbosscache-dev(a)lists.jboss.org
>> Subject: [jbosscache-dev] Perf tuning for JBoss Cache
>>
>> Guys,
>>
>> Every time we see or suspect potential inefficiencies in the JBoss
>> Cache codebase (stuff we spot while working on other features or
>> debugging stuff) we should note these down so they can be revisited
>> later.
>>
>> At some point I do want to do a full performance analysis as well,
>> but for the time being this could be useful to capture stuff we see
>> as we go along.
>>
>> http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCachePerfAnalysis
>>
>> 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, 5 months