RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
by Galder Zamarreno
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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years
RE: [jbosscache-dev] easing the path for clients to get aroundredeployment class loading issues in JBC
by Galder Zamarreno
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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
20 years
RE: [jbosscache-dev] easing the path for clients to get aroundredeployment class loading issues in JBC
by Brian Stansberry
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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
20 years
RE: easing the path for clients to get around redeployment class loading issues in JBC
by Galder Zamarreno
I'm not sure whether this got sent in the end or not.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Galder Zamarreno
Sent: 02 November 2006 11:44
To: jbosscache-dev(a)lists.jboss.org
Subject: easing the path for clients to get around redeployment class loading issues in JBC
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
20 years
easing the path for clients to get around redeployment class loading issues in JBC
by Galder Zamarreno
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
20 years
RE: [jbosscache-dev] JBoss Cache 1.4.1 && JGroups 2.4?
by Ben Wang
If QA is ok with it, I think we should go for it.
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, November 02, 2006 1:03 AM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBoss Cache 1.4.1 && JGroups 2.4?
What do people feel about shipping JBC 141 with JG 24?
Currently JBC 140 ships with JG 2.2.9.2.
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years
RE: [jbosscache-dev] RE:http://jira.jboss.com/jira/browse/JBCACHE-644
by Galder Zamarreno
+1 on warning messages.
I will also add a warning for paths longer than 255 characters which is a hard limit in Windows. I don't think this produces a exception but truncates the file.
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 Manik Surtani
Sent: 23 October 2006 18:31
To: jbosscache-dev(a)lists.jboss.org
Subject: Fwd: [jbosscache-dev] RE:http://jira.jboss.com/jira/browse/JBCACHE-644
I suppose given that we're not even recommending the FCL for most
production use cases, perhaps just log a warning in the FCL when such
characters are encountered, warning of the lack of portability and
the potential for an IOException?
>
>
>
> On 23 Oct 2006, at 17:13, Galder Zamarreno wrote:
>
>> Looking at this further, what do we wanna do if we encounter one
>> of this characters when creating the file/directory?
>>
>> We could substitute them for other allowed characters, but it
>> would also mean that a get operation would have to translate the
>> fqn to the allowed fqn with the substituted characters. We would
>> need some kind of mapping between the original fqn and the
>> translated one.
>>
>> Is it really worth doing this? The more I think about it, the more
>> I feel that it seems like adding an unnecessary layer of
>> complexity to the FCL, especially when there's a very easy
>> alternative to it, which is not using those characters.
>>
>> I found this article talking about differences between Linux, Mac
>> and Windows: http://linux.wordpress.com/2006/07/23/linux-mac-
>> windows-file-name-friction/
>>
>> Windows is definitely the most restrictive, but Linux and Mac
>> might sound more restrictive in this sense, but might have to get
>> around it to create files with these characters (use ' '
>> characters, or '\').
>>
>> It ends up saying:
>>
>> Avoid using these characaters
>> for maximum portability
>>
>> Asterisk *
>> Colon :
>> Back slash \
>> Forward slash /
>> Less Than <
>> Greater Than >
>> Pipe |
>> Quote "
>> Question mark ?
>>
>> What do you think? Is it really worth it?
>>
>> 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(a)lists.jboss.org] On Behalf Of Galder Zamarreno
>> Sent: 20 October 2006 12:00
>> To: Manik Surtani
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: [jbosscache-dev] RE: http://jira.jboss.com/jira/browse/
>> JBCACHE-644
>>
>> I'd stick to general rules.
>>
>> Cheers,
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: 20 October 2006 11:57
>> To: Galder Zamarreno
>> Cc: jbosscache-dev(a)lists.jboss.org
>> Subject: Re: http://jira.jboss.com/jira/browse/JBCACHE-644
>>
>> Yes, I think so ...
>>
>> Just be generic. Perhaps the FileCacheLoader could take an optional
>> property containing a list of OS-specific illegal characters for the
>> deployed platform, but then again if someone can specify this, they'd
>> know not to use these characters in the cache anyway.
>>
>> I'd just stick with the generic illegal chars.
>>
>>
>> --
>> 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 20 Oct 2006, at 10:48, Galder Zamarreno wrote:
>>
>>> There's a hard limit in Windows by which a file path cannot be
>>> bigger than 255 characters, so that's an OS limit itself.
>>>
>>> Illegal characters vary depending on the OS, but there's some that
>>> apply to all OS.
>>>
>>> How do you wanna approach this? Shall we focus on limitations
>>> applying to all OS? I doubt we wanna be coding something that is
>>> dependant on the OS.
>>>
>>> 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
20 years
RE: [jbosscache-dev] RE: JBossCache 1.4.1.Beta
by Galder Zamarreno
Guys, I guess you're referring to November? Unless you live in the past :)
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 Ryan Campbell
Sent: 31 October 2006 17:54
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: [jbosscache-dev] RE: JBossCache 1.4.1.Beta
Ok, this will work. Thanks, Manik!
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, October 31, 2006 10:51 AM
> To: Ryan Campbell
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: JBossCache 1.4.1.Beta
>
> On 31 Oct 2006, at 16:45, Ryan Campbell wrote:
>
> > Friday releases are impolite to QA who usually end up working well
> > into
> > Friday evening (especially after finding issues which you guys have
to
> > fix ;-).
>
> Good point - my apologies.
>
> >
> > I would rather do releases Monday-Wednesday. Could you able to
update
> > your schedule accordingly? I think we can handle this Friday, but
for
> > future releases I would prefer Monday-Wednesday.
>
> Ok, I could squeeze in something like:
>
> 1.4.1.CR1 - Thu 9th Oct
> 1.4.1.GA - Thu 16th Oct
>
> And thereafter, I'll make sure we do it earlier in the week. Is that
> ok?
>
> Cheers,
> Manik
>
> >
> > Thanks,
> > Ryan
> >
> >> -----Original Message-----
> >> From: Manik Surtani [mailto:manik@jboss.org]
> >> Sent: Tuesday, October 31, 2006 10:36 AM
> >> To: Ryan Campbell
> >> Cc: jbosscache-dev(a)lists.jboss.org; QA
> >> Subject: Re: JBossCache 1.4.1.Beta
> >>
> >> No worries. And as a heads-up, we hope to release:
> >>
> >> 1.4.1.CR1 - Fri 10th Oct
> >> 1.4.1.GA - Fri 17th Oct
> >>
> >> I know it is a pretty close schedule but 1.4.1 isn't far off from
> >> another SP on 1.4.0.
> >>
> >> Looking into the CC failures.
> >>
> >> 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 31 Oct 2006, at 16:25, Ryan Campbell wrote:
> >>
> >>> We can start the release on Friday; can you create the JBQA JIRA
> >>> release
> >>> issue? Also, we would like to have 2 weeks notice in the future.
> >>> This
> >>> allows us to plan around any competing priorities.
> >>>
> >>> I currently see 9 failures in cruisecontrol for the
> >>> jboss-cache-testsuite-140 run. We will want these resolved before
> >>> release.
> >>>
> >>> Thanks,
> >>> Ryan
> >>>
> >>>> -----Original Message-----
> >>>> From: Manik Surtani [mailto:manik@jboss.org]
> >>>> Sent: Tuesday, October 31, 2006 5:50 AM
> >>>> To: jbosscache-dev(a)lists.jboss.org
> >>>> Cc: QA
> >>>> Subject: JBossCache 1.4.1.Beta
> >>>>
> >>>> Guys, I'm hoping to tag this release on Friday AM my time. QA,
do
> >>>> you think you'd be able to do this release on Fri?
> >>>>
> >>>> Cheers,
> >>>> --
> >>>> Manik Surtani
> >>>>
> >>>> Lead, JBoss Cache
> >>>> JBoss, a division of Red Hat
> >>>>
> >>>> Email: manik(a)jboss.org
> >>>> Telephone: +44 7786 702 706
> >>>> MSN: manik(a)surtani.org
> >>>> Yahoo/AIM/Skype: maniksurtani
> >>>>
> >>>
> >
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years
RE: [jbosscache-dev] JBoss Cache 1.4.1 && JGroups 2.4?
by Galder Zamarreno
I haven't seen people complaining about binary compatibility when upgrading from 2.2.x to 2.3.x. They're seem to be always be happy about upgrading all their JBC instances in the cluster (and JGroups as well).
So, +1 here
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 Manik Surtani
Sent: 01 November 2006 18:03
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] JBoss Cache 1.4.1 && JGroups 2.4?
What do people feel about shipping JBC 141 with JG 24?
Currently JBC 140 ships with JG 2.2.9.2.
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
20 years
JBoss Cache 1.4.1 && JGroups 2.4?
by Manik Surtani
What do people feel about shipping JBC 141 with JG 24?
Currently JBC 140 ships with JG 2.2.9.2.
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
20 years
