August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6920) ClusteredGetCommand always uses anycast branch in JGroupsTransport

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6920: --------------------------------- Summary: ClusteredGetCommand always uses anycast branch in JGroupsTransport Key: ISPN-6920 URL: https://issues.jboss.org/browse/ISPN-6920 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Assignee: Dan Berindei Since ISPN-1934 RPCs ignoring leavers (and that includes {{WAIT_FOR_VALID_RESPONSE}}) always use the anycast branch, even if there's single node to which the command is sent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6914) Upgrade to WildFly 10.1.0.CR1

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6914?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6914: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha4 9.0.0.Final Resolution: Done > Upgrade to WildFly 10.1.0.CR1 > ----------------------------- > > Key: ISPN-6914 > URL: https://issues.jboss.org/browse/ISPN-6914 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha4, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6907) Replicated cache with BATCH Transactions do not respect shared store semantics

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6907?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6907: ------------------------------- Status: Open (was: New) > Replicated cache with BATCH Transactions do not respect shared store semantics > ------------------------------------------------------------------------------ > > Key: ISPN-6907 > URL: https://issues.jboss.org/browse/ISPN-6907 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.3.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 8.2.4.Final > > > When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write. > So far I haven't been able to reproduce this issue on the master branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6907) Replicated cache with BATCH Transactions do not respect shared store semantics

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6907?page=com.atlassian.jira.plugin.... ] Work on ISPN-6907 started by Ryan Emerson. ------------------------------------------ > Replicated cache with BATCH Transactions do not respect shared store semantics > ------------------------------------------------------------------------------ > > Key: ISPN-6907 > URL: https://issues.jboss.org/browse/ISPN-6907 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.2.3.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 8.2.4.Final > > > When running a replicated cache with transaction mode=BATCH and a shared cache store, it is possible for more than one node to write the store. This does not occur on every batch write. > So far I haven't been able to reproduce this issue on the master branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4915) Support flags for REST endpoint

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4915?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4915: ---------------------------------- Labels: hackathon (was: ) > Support flags for REST endpoint > ------------------------------- > > Key: ISPN-4915 > URL: https://issues.jboss.org/browse/ISPN-4915 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Tristan Tarrant > Labels: hackathon > > For protocol symmetry, we should add support for the operation flags (e.g. SKIP_CACHE_LOAD, SKIP_INDEXING, etc) on the REST operations using some form of custom header -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2016