[JBoss JIRA] (ISPN-5949) AbstractFileLookup.lookupFileStrict does not use specified classloader
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5949?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5949:
-----------------------------------
Affects Version/s: 8.2.3.Final
(was: 8.0.1.Final)
(was: 8.1.0.Beta1)
> AbstractFileLookup.lookupFileStrict does not use specified classloader
> ----------------------------------------------------------------------
>
> Key: ISPN-5949
> URL: https://issues.jboss.org/browse/ISPN-5949
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.5.Final, 8.2.3.Final
> Reporter: Stéphane Nicoll
> Assignee: Sebastian Łaskawiec
> Fix For: 9.0.0.Alpha4, 9.0.0.Final
>
>
> I am reporting this issue on behalf of a Spring Boot user that created [an issue in our tracker|https://github.com/spring-projects/spring-boot/issues/4418].
> Spring Boot creates a JCache manager using the standard API, passing a {{Classloader}} to it. It's unclear at this point if we pass the proper classloader or not but it doesn't matter that much at this point since the classloader argument is being ignored by {{AbstractFileLookup.lookupFileStrict}}.
> {noformat}
> Caused by: java.lang.IllegalArgumentException: URI is not hierarchical
> at java.io.File.<init>(File.java:418)
> at org.infinispan.commons.util.AbstractFileLookup.lookupFileStrict(AbstractFileLookup.java:63)
> at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:98)
> at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
> at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:66)
> at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:97)
> at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.jCacheCacheManager(JCacheCacheConfiguration.java:80)
> {noformat}
> When not running as a fat jar (i.e. running the main class in the IDE), the code works as expected (as the classloader does not matter in this case).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6911) Add a MANUAL strategy to eviction
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6911?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6911:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Alpha4
9.0.0.Final
Resolution: Done
> Add a MANUAL strategy to eviction
> ---------------------------------
>
> Key: ISPN-6911
> URL: https://issues.jboss.org/browse/ISPN-6911
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Alpha4, 9.0.0.Final
>
>
> Currently the eviction configuration validation logs a warning when passivation is enabled without an eviction strategy (common with WildFly, where eviction is performed manually).
> To silence an otherwise misleading error message when the user is fully aware of the behaviour, we can introduce a MANUAL strategy
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-4910) Document inconsistent behavior of ReadCommitted isolation level in some scenarios
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4910:
-------------------------------------
Assignee: Dan Berindei
> Document inconsistent behavior of ReadCommitted isolation level in some scenarios
> ---------------------------------------------------------------------------------
>
> Key: ISPN-4910
> URL: https://issues.jboss.org/browse/ISPN-4910
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.0.CR2
> Reporter: Martin Gencur
> Assignee: Dan Berindei
>
> Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html:
> {code:java}
> public void testSizeWithPreviousRead() throws Exception {
> tm(0).begin();
> cache(0).put(k0, "v0");
> cache(0).put(k1, "v1");
> assertEquals(2, cache(0).size());
> tm(0).commit();
> tm(0).begin();
> //make sure we read k1 in this transaction
> assertEquals("v1", cache(0).get(k1));
> final Transaction tx1 = tm(0).suspend();
> //another tx working on the same keys
> tm(0).begin();
> //remove the key that was previously read in another tx
> cache(0).remove(k1);
> cache(0).put(k0, "v2");
> tm(0).commit();
> tm(0).resume(tx1);
> //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account
> assertEquals(1, cache(0).size());
> //^^^^^ the test fails here, cache.size() return 2 instead of expected 1
> assertEquals("v2", cache(0).get(k0));
> assertNull(cache(0).get(k1));
> tm(0).commit();
> assertNull(cache(1).get(k1));
> }
> {code}
> I will add tests as part of ISPN-4820 to show the behavior, we just need to document it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-4910) Document inconsistent behavior of ReadCommitted isolation level in some scenarios
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4910:
---------------------------------------
[~dan.berindei] can this be closed ?
> Document inconsistent behavior of ReadCommitted isolation level in some scenarios
> ---------------------------------------------------------------------------------
>
> Key: ISPN-4910
> URL: https://issues.jboss.org/browse/ISPN-4910
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.0.CR2
> Reporter: Martin Gencur
> Assignee: Dan Berindei
>
> Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html:
> {code:java}
> public void testSizeWithPreviousRead() throws Exception {
> tm(0).begin();
> cache(0).put(k0, "v0");
> cache(0).put(k1, "v1");
> assertEquals(2, cache(0).size());
> tm(0).commit();
> tm(0).begin();
> //make sure we read k1 in this transaction
> assertEquals("v1", cache(0).get(k1));
> final Transaction tx1 = tm(0).suspend();
> //another tx working on the same keys
> tm(0).begin();
> //remove the key that was previously read in another tx
> cache(0).remove(k1);
> cache(0).put(k0, "v2");
> tm(0).commit();
> tm(0).resume(tx1);
> //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account
> assertEquals(1, cache(0).size());
> //^^^^^ the test fails here, cache.size() return 2 instead of expected 1
> assertEquals("v2", cache(0).get(k0));
> assertNull(cache(0).get(k1));
> tm(0).commit();
> assertNull(cache(1).get(k1));
> }
> {code}
> I will add tests as part of ISPN-4820 to show the behavior, we just need to document it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months