[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6554:
----------------------------------------
Good to know, I'll pull out the latest ci build and test this tomorrow.
I'll open a new issue, if necessary.
Thanks again !
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6554:
------------------------------------
I believe you are running into WFLY-6674 - a fix for which was just merged into master.
The description of WFLY-6674 is a bit deceiving - essentially, cache configurations specified in the Infinispan subsystem were not being defined eagerly, but lazily when the appropriate dependencies are established.
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6554:
----------------------------------------
Hi [~pferraro], sorry for taking so long, but I've found the NPE issue I was having.
We use a stripped down version of standalone.xml.
Since we are relying on Spring for the EntityManager bootstrapping, we excluded the JPA subsystem.
By excluding that subsystem, the org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener SPI was not available within the classpath, hence:
{code}
try {
// start a private cache for non-JPA use and return the started cache.
wrapper = Notification.startCache(Classification.INFINISPAN, cacheSettings);
return (EmbeddedCacheManager)wrapper.getValue();
} catch (Exception e) {
throw new CacheException(e);
}
public static Wrapper startCache(Classification cacheType, Properties properties) throws Exception {
Wrapper result = null;
for(EventListener eventListener: eventListeners) {
Wrapper value = eventListener.startCache(cacheType, properties);
if (value != null && result == null) {
result = value; // return the first non-null wrapper value returned from a listener
}
}
return result;
}
{code}
wrapper was always null, since there was no listener at all.
I know our use case might be a little bit weird but maybe there's some validation or warning missing around here?
That said, after that I was able to use the 'org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory' without any exception.
There's still one problem though, all the caches configuration are still not yet defined properly. All my "entity" cache inherit from the default cache i.e. "local-query".
I've also tried the 'org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory' but got also the exact same behavior.
Could it be possible that the configuration is picked up from inside one of the hibernate jars instead of the one defined in the infinispan subsystem?
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6674?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6674 at 6/6/16 2:11 PM:
------------------------------------------------------------
While the MSC service providing the cache configuration is installed as PASSIVE, the cache configuration components on which it depends are installed as ON_DEMAND. These should be PASSIVE as well.
was (Author: pferraro):
While the MSC service providing the cache configuration is installed as PASSIVE, the cache configuration components on which it depends are installed as ON_DEMAND. These should really PASSIVE as well.
> Infinispan subsystem cache configuration is lost when cache is created
> ----------------------------------------------------------------------
>
> Key: WFLY-6674
> URL: https://issues.jboss.org/browse/WFLY-6674
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Windows 10
> Wildfly 10.0.0.Final
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
> Labels: cache, configuration, infinispan
> Fix For: 10.1.0.Final
>
>
> Infinispan subsystem configuration is lost when cache is created.
> If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
> https://github.com/arielcarrera/test-infinispan-wildfly10
> After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
> This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
> Entities never expire/invalidate. The lifespan/max-entries are set to -1.
> I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6674?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6674:
-------------------------------
Fix Version/s: 10.1.0.Final
> Infinispan subsystem cache configuration is lost when cache is created
> ----------------------------------------------------------------------
>
> Key: WFLY-6674
> URL: https://issues.jboss.org/browse/WFLY-6674
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Windows 10
> Wildfly 10.0.0.Final
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
> Labels: cache, configuration, infinispan
> Fix For: 10.1.0.Final
>
>
> Infinispan subsystem configuration is lost when cache is created.
> If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
> https://github.com/arielcarrera/test-infinispan-wildfly10
> After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
> This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
> Entities never expire/invalidate. The lifespan/max-entries are set to -1.
> I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6674) Infinispan subsystem cache configuration is lost when cache is created
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6674?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6674:
------------------------------------
While the MSC service providing the cache configuration is installed as PASSIVE, the cache configuration components on which it depends are installed as ON_DEMAND. These should really PASSIVE as well.
> Infinispan subsystem cache configuration is lost when cache is created
> ----------------------------------------------------------------------
>
> Key: WFLY-6674
> URL: https://issues.jboss.org/browse/WFLY-6674
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Windows 10
> Wildfly 10.0.0.Final
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
> Labels: cache, configuration, infinispan
>
> Infinispan subsystem configuration is lost when cache is created.
> If it is helpful, I made a simple test project to validate the problem. It is prepared to run with Wildfly 8 and 10.
> https://github.com/arielcarrera/test-infinispan-wildfly10
> After startup and created the cache, it is not configured with the specified settings in Wildfly's Infinispan Subsystem.
> This can be verified by monitoring the jboss.infinispan nodes with JConsole retrieving the cache settings or running my simple test project.
> Entities never expire/invalidate. The lifespan/max-entries are set to -1.
> I found an old issue (https://issues.jboss.org/browse/WFLY-3858) about wildfly 8 but this problem talks about a security config problem and is a little different. It is a problem about wildfly 10 configuration and it is working OK on wildfly 8.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
by Viacheslav Krot (JIRA)
Viacheslav Krot created DROOLS-1199:
---------------------------------------
Summary: Memory leak in KieScanner
Key: DROOLS-1199
URL: https://issues.jboss.org/browse/DROOLS-1199
Project: Drools
Issue Type: Bug
Reporter: Viacheslav Krot
Assignee: Mark Proctor
I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
Eventually application fails with OOM.
As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months