RE: [jbosscache-dev] JBCACHE-874 (WAS: JBCACHE-315 and 1.4.1)
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Manik Surtani wrote:
>> Yeah, I may do a CR1 tomorrow anyway, and get JBCACHE-315 and JGroups
>> 2.4.1 in CR2 now. There are enough changes from fixing
>> JBCACHE-871 and JBCACHE-875 to warrant a CR, as these are pretty big
>> changes.
>
> It's not a big deal if JBCACHE-874 doesn't go in 1.4.1.CR1,
> but it would be nice to get it in so it's out in the wild
> longer before the GA.
>
> This is a switch from LinkedList to LinkedHashSet as the data
> structure in TransactionEntry; there's a forum post linked to
> the JIRA that explains why.
>
> I can probably do this today, but wanted to point out a
> couple things and get feedback:
>
> 1) A bunch of the LinkedList fields in TransactionEntry are protected.
> Changing them to LinkedHashSet therefore technically changes the API.
> This is an internal class, so I don't think that's an issue.
> Any objections?
>
> 2) A number of TransactionEntry methods return List and
> currently hand out a ref to the internal data structure. The
> caller of these methods logically expects a List so I think
> the API should remain the same. So, that implies the methods
> would do something like "return new ArrayList(internalSet);"
>
>
> If there are any concerns about this, it doesn't need to get
> done today or go in CR1.
>
Replying to myself :(
Had a look at some of the uses of the TransactionEntry methods that
return List and at least some are frequently used and don't need List
semantics (e.g. CacheLoaderInterceptor.wasRemovedInTx().) So copying off
the Set to a List to satisfy these calls is unnecessary overhead. I
think JBCACHE-874 needs a bit more thought, so I'm not going to try to
rush it in one day.
17 years, 4 months
RE: [jbosscache-dev] JBCACHE-315 and 1.4.1
by Vladimir Blagojevic
Bela has to approve fix for mux service view block/unblock
problem that we have mentioned. After that I am working on
315 until it is resolved.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Friday, December 01, 2006 12:25 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] JBCACHE-315 and 1.4.1
>
> Ok, looks like we need to target 1.4.1 for AS 4.2 - there is
> no way we can get a 2.0.0.GA by the end of Dec. It is still
> in ALPHA1.
>
> Vladimir, looks like we'll need JBCACHE-315 for the next
> 1.4.1 release (CR1) then. Do you think you'd have time next
> week for this?
>
> Bela, JG 2.4.1 will also be needed for this release, but I
> think timescales will be dictated by JBCACHE-315.
>
> 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, 4 months
JBCACHE-315 and 1.4.1
by Manik Surtani
Ok, looks like we need to target 1.4.1 for AS 4.2 - there is no way
we can get a 2.0.0.GA by the end of Dec. It is still in ALPHA1.
Vladimir, looks like we'll need JBCACHE-315 for the next 1.4.1
release (CR1) then. Do you think you'd have time next week for this?
Bela, JG 2.4.1 will also be needed for this release, but I think
timescales will be dictated by JBCACHE-315.
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] Anycast: JBCACHE-813 & JGRP-338
by Brian Stansberry
Re: making multiple unicast calls from the JBC layer, doesn't this
likely increase the overall time to do the group RPC by putting each
call/response in series? You lose JGroups' ability to correlate the
responses.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yes, you could call
> getChannel().getProtocolStack().findProtocol("UDP")
> to do this.
>
> I discussed this yesterday, and the impl of anycast is really
> quite simple. I'll do this next week.
>
> Manik Surtani wrote:
>>
>>
>> On 27 Nov 2006, at 22:01, Bela Ban wrote:
>>
>>>
>>>
>>> Manik Surtani wrote:
>>>> 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
>>>
>>> yes
>>>
>>>> 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).
>>>
>>> Right (http://jira.jboss.com/jira/browse/JGRP-338)
>>>
>>>> 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.
>>>
>>> Correct. I think anycast will be relatively simple to implement. In
>>> the meantime, you could simply send 3 unicasts yourself, e.g. for
>>> sending the message to A, B and C:
>>> callRemoteMethod(A, "foo", new Object[]{"bla", new Integer(2662)},
>>> new Class[]{String.class, Integer.class}, ...); callRemoteMethod(B,
>>> "foo", new Object[]{"bla", new Integer(2662)}, new
>>> Class[]{String.class, Integer.class}, ...); callRemoteMethod(C,
>>> "foo", new Object[]{"bla", new Integer(2662)}, new
>>> Class[]{String.class, Integer.class}, ...);
>>>
>>> This should do the job.
>>>
>>>> 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.
>>>
>>> Yes, the idea is to let the transport handle optimal message
>>> distribution, e.g. as described in the above JIRA issue. This will
>>> be available in 2.5.
>>>
>>
>> Another option (equally hacky, but again temporary until JG 2.5) is
>> for TreeCache (or RpcManager in 2.0.0) to test whether UDP is a
>> registered protocol in the channel (Iterate through the Vector
>> returned by channel.getProtocolStack().getProtocols() and look for an
>> instance of o.j.p.UDP). If UDP is registered, then ALWAYS use
>> callRemoteMethods() otherwise ALWAYS use separate callRemoteMethod()
>> invocations.
>>
>> Which would be cleaner/more efficient? I'd go for option 2, provided
>> there is no efficiency lost when broadcasting to the entire cluster
>> using a series of callRemoteMethod() invocations over a single
>> callRemoteMethods() invocation when using TCP.
17 years, 5 months
RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
by Galder Zamarreno
done
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: 30 November 2006 03:15
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
Yes pls
--
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 29 Nov 2006, at 18:41, Galder Zamarreno wrote:
> Btw, I have committed it to Branch_JBossCache_1_4_0.
>
> Do we want this in HEAD as well? I guess so, but just double
> checking here.
>
> 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: Galder Zamarreno
> Sent: 29 November 2006 19:40
> To: 'Manik Surtani'
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] easing the path for
> clientstogetaroundredeployment class loading issues in JBC
>
> Ok, sounds good.
>
> I have committed the UT (o.j.c.m.RedeploymentEmulationTest) and the
> QA entry.
>
> 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: 28 November 2006 23:31
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] easing the path for
> clientstogetaroundredeployment class loading issues in JBC
>
> Comments below:
>
> On 28 Nov 2006, at 19:32, Galder Zamarreno wrote:
>
>> 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?
>
>
> I'd change this to:
>
> the <literal>useRegionBasedMarshalling</literal> attribute in JBoss
> Cache ...
>
>>
>> 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.
>>
>
> This is slightly incorrect. The original use case was a workaround
> for replicated caches that did not have context classloaders
> registered. In 1.4.x, I added the JBoss Serialization stuff and the
> magic numbers for known types for performance.
>
>> 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(a)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: intellij 5 linux
by Manik Surtani
Well, let's chat about this on the forums or on jbosscache-
dev(a)lists.jboss.org
IDEA 6 is much, much better than 5. A worthwhile upgrade.
--
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 30 Nov 2006, at 15:50, Heiko Braun wrote:
> actually we are just discussing integration of jbossCache with
> jbossws for certain features. maybe this brings up some issues ...
>
> thanks
>
> Manik Surtani schrieb:
>> Here you go - call this a bribe so you will contrib some code to
>> JBoss Cache in the future. :-)
>> User Name: JBossCache
>> License key 1: 25392-WSW2M-95ZOH-DWPNS-ZC4RR-IXQU6
>> --
>> 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 30 Nov 2006, at 15:42, Heiko Braun wrote:
>>> hehe, i will think about it ;)
>>>
>>> /Heiko
>>>
>>> Manik Surtani schrieb:
>>>> Well, if you contributed some code to JBoss Cache I could give
>>>> you a copy of the JBoss Cache license... ;)
>>>> --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 30 Nov 2006, at 15:34, Heiko Braun wrote:
>>>>> unfortunately mine doesn't.
>>>>>
>>>>> /Heiko
>>>>>
>>>>> Manik Surtani schrieb:
>>>>>> Don't licenses for IDEA 5 work on IDEA 6 as well? Mine did,
>>>>>> both on Linux and OS X. Not sure if it was something specific
>>>>>> about my license though (a free license donated by Jetbrains
>>>>>> for JBoss Cache)
>>>>>> --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 30 Nov 2006, at 14:25, Heiko Braun wrote:
>>>>>>> I own a license for it.
>>>>>>> But I just realized that it's still available from JetBrains.
>>>>>>>
>>>>>>> Tnx
>>>>>>>
>>>>>>>
>>>>>>> Manik Surtani schrieb:
>>>>>>>> Not 5. Why would you want 5 anyhows?
>>>>>>>> --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 30 Nov 2006, at 14:10, Heiko Braun wrote:
>>>>>>>>>
>>>>>>>>> does some still have an intellij 5 linux installer available?
>>>>>>>>>
>>>>>>>>> /Heiko
>>>>>>>
>>>>>>> ----
>>>>>>> Heiko Braun
>>>>>>> JBoss, a division of Red Hat
>>>>>>> T: +49 89 52350383
>>>>>>> M: +49 178 1496854
>>>>>
>>>>> ----
>>>>> Heiko Braun
>>>>> JBoss, a division of Red Hat
>>>>> T: +49 89 52350383
>>>>> M: +49 178 1496854
>>>
>>> ----
>>> Heiko Braun
>>> JBoss, a division of Red Hat
>>> T: +49 89 52350383
>>> M: +49 178 1496854
>
> --
> --
> Heiko Braun
> JBoss, a division of Red Hat
> T: +49 89 52350383
> M: +49 178 1496854
17 years, 5 months
Re: Fundamental problem with pessimistic locking
by Manik Surtani
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] Re: intellij 5 linux
by Ben Wang
I also use 6 but haven't noticed any slowdown.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Bela Ban
Sent: Friday, December 01, 2006 12:51 AM
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org; Heiko Braun
Subject: Re: [jbosscache-dev] Re: intellij 5 linux
Really ? Lots of people said 6 was much slower than 5, that's the main reason I haven't tried it out yet
Manik Surtani wrote:
> Well, let's chat about this on the forums or on
> jbosscache-dev(a)lists.jboss.org
>
> IDEA 6 is much, much better than 5. A worthwhile upgrade.
> --
> 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 30 Nov 2006, at 15:50, Heiko Braun wrote:
>
>> actually we are just discussing integration of jbossCache with
>> jbossws for certain features. maybe this brings up some issues ...
>>
>> thanks
>>
>> Manik Surtani schrieb:
>>> Here you go - call this a bribe so you will contrib some code to
>>> JBoss Cache in the future. :-) User Name: JBossCache License key 1:
>>> 25392-WSW2M-95ZOH-DWPNS-ZC4RR-IXQU6
>>> --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 30 Nov 2006, at 15:42, Heiko Braun wrote:
>>>> hehe, i will think about it ;)
>>>>
>>>> /Heiko
>>>>
>>>> Manik Surtani schrieb:
>>>>> Well, if you contributed some code to JBoss Cache I could give you
>>>>> a copy of the JBoss Cache license... ;) --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 30 Nov 2006, at 15:34, Heiko Braun wrote:
>>>>>> unfortunately mine doesn't.
>>>>>>
>>>>>> /Heiko
>>>>>>
>>>>>> Manik Surtani schrieb:
>>>>>>> Don't licenses for IDEA 5 work on IDEA 6 as well? Mine did,
>>>>>>> both on Linux and OS X. Not sure if it was something specific
>>>>>>> about my license though (a free license donated by Jetbrains for
>>>>>>> JBoss Cache) --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 30 Nov 2006, at 14:25, Heiko Braun wrote:
>>>>>>>> I own a license for it.
>>>>>>>> But I just realized that it's still available from JetBrains.
>>>>>>>>
>>>>>>>> Tnx
>>>>>>>>
>>>>>>>>
>>>>>>>> Manik Surtani schrieb:
>>>>>>>>> Not 5. Why would you want 5 anyhows?
>>>>>>>>> --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 30 Nov 2006, at 14:10, Heiko Braun wrote:
>>>>>>>>>>
>>>>>>>>>> does some still have an intellij 5 linux installer available?
>>>>>>>>>>
>>>>>>>>>> /Heiko
>>>>>>>>
>>>>>>>> ----
>>>>>>>> Heiko Braun
>>>>>>>> JBoss, a division of Red Hat
>>>>>>>> T: +49 89 52350383
>>>>>>>> M: +49 178 1496854
>>>>>>
>>>>>> ----
>>>>>> Heiko Braun
>>>>>> JBoss, a division of Red Hat
>>>>>> T: +49 89 52350383
>>>>>> M: +49 178 1496854
>>>>
>>>> ----
>>>> Heiko Braun
>>>> JBoss, a division of Red Hat
>>>> T: +49 89 52350383
>>>> M: +49 178 1496854
>>
>> ----
>> Heiko Braun
>> JBoss, a division of Red Hat
>> T: +49 89 52350383
>> M: +49 178 1496854
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
--
Bela Ban
Lead JGroups / JBoss Clustering team
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, 5 months