[infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Manik Surtani-2
Sanne,

WRT https://issues.jboss.org/browse/ISPN-1374 

I don't see the class loader being ignored?  It is used to load the module.properties file (by passing it into FileLookup [1]).  FileLookup has a regular impl as well as an OSGi impl which is capable of scanning different bundles.  Have you seen any specific bugs around this?

Cheers
Manik



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Sanne Grinovero-3
Hi,
I'm not suggesting that the classloader is completely ignored; it is
indeed evaluated at the first invocation but then if the following
method is invoked again with a different classloader as argument, it
will return the previously cached value:

https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/ModuleProperties.java#L135

Note that the method you pointed to is private, and is actually a
helper for the public methods, which does cache all of it's results in
static fields.

So assuming this will be invoked by a single classloader only, indeed
there are no issues. But is that really the case?
Wasn't the purpose of the classloader parameter to load extensions
from a deployed application? If so, it seems I can't deploy two
different applications both attempting to start an Infinispan
cachemanager.

For example, I suspect that you won't be able to deploy an Hibernate
Search application (or Infinispan Query) and then deploy a Hibernate
OGM based application in the same container.
But this is not proven as I didn't try it out, so maybe my assumptions
about what the goal of this classloader parameter are wrong.

So I think that, iff we need to cache this information, it shouldn't
be cached in a static field, as discussed as well on
https://issues.jboss.org/browse/ISPN-1190

Cheers,
Sanne

On 12 September 2011 19:10, Manik Surtani <[hidden email]> wrote:

> Sanne,
> WRT https://issues.jboss.org/browse/ISPN-1374
> I don't see the class loader being ignored?  It is used to load the
> module.properties file (by passing it into FileLookup [1]).  FileLookup has
> a regular impl as well as an OSGi impl which is capable of scanning
> different bundles.  Have you seen any specific bugs around this?
> Cheers
> Manik
> [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/ModuleProperties.java#L112
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Manik Surtani

On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:

> Hi,
> I'm not suggesting that the classloader is completely ignored; it is
> indeed evaluated at the first invocation but then if the following
> method is invoked again with a different classloader as argument, it
> will return the previously cached value:
>
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/ModuleProperties.java#L135
>
> Note that the method you pointed to is private, and is actually a
> helper for the public methods, which does cache all of it's results in
> static fields.
>
> So assuming this will be invoked by a single classloader only, indeed
> there are no issues. But is that really the case?
> Wasn't the purpose of the classloader parameter to load extensions
> from a deployed application? If so, it seems I can't deploy two
> different applications both attempting to start an Infinispan
> cachemanager.

Well, why would the class loader in this case make a difference, unless you are in an OSGi environment?  Remember that this isn't used to load application classes.  Just Infinispan module classes.  In this case the OSGi file lookup should be able to handle the appropriate loader for each bundle/module.  Will need to make sure this works for JBoss AS 7 modules too.

>
> For example, I suspect that you won't be able to deploy an Hibernate
> Search application (or Infinispan Query) and then deploy a Hibernate
> OGM based application in the same container.
> But this is not proven as I didn't try it out, so maybe my assumptions
> about what the goal of this classloader parameter are wrong.

Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.

> So I think that, iff we need to cache this information, it shouldn't
> be cached in a static field, as discussed as well on

Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?

Cheers
Manik
--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Sanne Grinovero-3
On 14 September 2011 17:37, Manik Surtani <[hidden email]> wrote:
>
> On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:
>> For example, I suspect that you won't be able to deploy an Hibernate
>> Search application (or Infinispan Query) and then deploy a Hibernate
>> OGM based application in the same container.
>> But this is not proven as I didn't try it out, so maybe my assumptions
>> about what the goal of this classloader parameter are wrong.
>
> Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.

Exactly the point. Unless you can make sure that both OGM and Search
are included in AS7 and special purpose caches are pre-configured out
of the box :-)

>
>> So I think that, iff we need to cache this information, it shouldn't
>> be cached in a static field, as discussed as well on
>
> Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?

Since caches can be started only once and should happen in the context
of a startCaches( ... ) context, such a cache could live in the scope
of such an invocation.
Besides solving the (potential?) problem that would also save some
memory as this information would be released right after usage.

I don't think people will be able to reuse the AS7 managed caches for
the purpose of Search or OGM, as for these reasons such extensions
should be available at AS7 boot-time, so we should at least make sure
that starting your own EmbeddedCacheManager is an option, otherwise
I'll be left with two options none of them viable.

Cheers,
Sanne

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Galder Zamarreno

On Sep 14, 2011, at 5:53 PM, Sanne Grinovero wrote:

> On 14 September 2011 17:37, Manik Surtani <[hidden email]> wrote:
>>
>> On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:
>>> For example, I suspect that you won't be able to deploy an Hibernate
>>> Search application (or Infinispan Query) and then deploy a Hibernate
>>> OGM based application in the same container.
>>> But this is not proven as I didn't try it out, so maybe my assumptions
>>> about what the goal of this classloader parameter are wrong.
>>
>> Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.
>
> Exactly the point. Unless you can make sure that both OGM and Search
> are included in AS7 and special purpose caches are pre-configured out
> of the box :-)
>
>>
>>> So I think that, iff we need to cache this information, it shouldn't
>>> be cached in a static field, as discussed as well on
>>
>> Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?
>
> Since caches can be started only once and should happen in the context
> of a startCaches( ... ) context, such a cache could live in the scope
> of such an invocation.
> Besides solving the (potential?) problem that would also save some
> memory as this information would be released right after usage.

Remember that a cache could be restarted...

>
> I don't think people will be able to reuse the AS7 managed caches for
> the purpose of Search or OGM, as for these reasons such extensions
> should be available at AS7 boot-time, so we should at least make sure
> that starting your own EmbeddedCacheManager is an option, otherwise
> I'll be left with two options none of them viable.
>
> Cheers,
> Sanne
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Sanne Grinovero-3
On 15 September 2011 17:25, Galder Zamarreño <[hidden email]> wrote:

>
> On Sep 14, 2011, at 5:53 PM, Sanne Grinovero wrote:
>
>> On 14 September 2011 17:37, Manik Surtani <[hidden email]> wrote:
>>>
>>> On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:
>>>> For example, I suspect that you won't be able to deploy an Hibernate
>>>> Search application (or Infinispan Query) and then deploy a Hibernate
>>>> OGM based application in the same container.
>>>> But this is not proven as I didn't try it out, so maybe my assumptions
>>>> about what the goal of this classloader parameter are wrong.
>>>
>>> Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.
>>
>> Exactly the point. Unless you can make sure that both OGM and Search
>> are included in AS7 and special purpose caches are pre-configured out
>> of the box :-)
>>
>>>
>>>> So I think that, iff we need to cache this information, it shouldn't
>>>> be cached in a static field, as discussed as well on
>>>
>>> Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?
>>
>> Since caches can be started only once and should happen in the context
>> of a startCaches( ... ) context, such a cache could live in the scope
>> of such an invocation.
>> Besides solving the (potential?) problem that would also save some
>> memory as this information would be released right after usage.
>
> Remember that a cache could be restarted...

Since it's just caching class/resources information we can re-scan in
any case you would need it.

But in which cases should a cache be restarted? shouldn't it be better
to throw away the CacheManager and create a new one?
I'm assuming you can't restart a single cache while maintaining the
others available as that would break 1) asymmetric clusters limitation
2) requirement to start them all together.

Cheers,
Sanne

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Galder Zamarreno

On Sep 16, 2011, at 1:09 AM, Sanne Grinovero wrote:

> On 15 September 2011 17:25, Galder Zamarreño <[hidden email]> wrote:
>>
>> On Sep 14, 2011, at 5:53 PM, Sanne Grinovero wrote:
>>
>>> On 14 September 2011 17:37, Manik Surtani <[hidden email]> wrote:
>>>>
>>>> On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:
>>>>> For example, I suspect that you won't be able to deploy an Hibernate
>>>>> Search application (or Infinispan Query) and then deploy a Hibernate
>>>>> OGM based application in the same container.
>>>>> But this is not proven as I didn't try it out, so maybe my assumptions
>>>>> about what the goal of this classloader parameter are wrong.
>>>>
>>>> Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.
>>>
>>> Exactly the point. Unless you can make sure that both OGM and Search
>>> are included in AS7 and special purpose caches are pre-configured out
>>> of the box :-)
>>>
>>>>
>>>>> So I think that, iff we need to cache this information, it shouldn't
>>>>> be cached in a static field, as discussed as well on
>>>>
>>>> Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?
>>>
>>> Since caches can be started only once and should happen in the context
>>> of a startCaches( ... ) context, such a cache could live in the scope
>>> of such an invocation.
>>> Besides solving the (potential?) problem that would also save some
>>> memory as this information would be released right after usage.
>>
>> Remember that a cache could be restarted...
>
> Since it's just caching class/resources information we can re-scan in
> any case you would need it.
>
> But in which cases should a cache be restarted? shouldn't it be better
> to throw away the CacheManager and create a new one?

I was just thinking that the other day. Originally, the cache restart thing came from me playing around with RHQ management (back in 4.0). I don't recall any particular external requirement on this.

> I'm assuming you can't restart a single cache while maintaining the
> others available as that would break 1) asymmetric clusters limitation
> 2) requirement to start them all together.

Yeah, these days 1) and 2) have become more common problem, and restarting, without being a cluster wide operation, can lead to unexpected results.

When it comes to stop at least, there's  ECM.removeCache() which is cluster wide. Stops and removes content of a cache cluster wide.

There's no equivalent for start.

>
> Cheers,
> Sanne
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev