March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4111) Fix dependency tree still leaking Netty 3 on Hot Rod classpath

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4111?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4111: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2436 > Fix dependency tree still leaking Netty 3 on Hot Rod classpath > -------------------------------------------------------------- > > Key: ISPN-4111 > URL: https://issues.jboss.org/browse/ISPN-4111 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha2 > > > Netty 3 is still present in the project because of missed exclusions via Narayana JTA. It's also still being used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4111) Fix dependency tree still leaking Netty 3 on Hot Rod classpath

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4111: ------------------------------------- Summary: Fix dependency tree still leaking Netty 3 on Hot Rod classpath Key: ISPN-4111 URL: https://issues.jboss.org/browse/ISPN-4111 Project: Infinispan Issue Type: Bug Components: Remote Protocols Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 7.0.0.Alpha2 Netty 3 is still present in the project because of missed exclusions via Narayana JTA. It's also still being used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4110) A Custom-store should be able to set dependencies to external resources like datasource-subsystem to prevent from startup problems in server mode

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-4110: -------------------------------------- Summary: A Custom-store should be able to set dependencies to external resources like datasource-subsystem to prevent from startup problems in server mode Key: ISPN-4110 URL: https://issues.jboss.org/browse/ISPN-4110 Project: Infinispan Issue Type: Enhancement Affects Versions: 7.0.0.Alpha1, 6.0.1.Final, 6.0.0.Final Reporter: Wolf-Dieter Fink Assignee: Tristan Tarrant If a custom store is configured like shown below the infinispan system does not know which dependency to set as this is done if a standard *keyed-jdbc-store is used. So the cache-store implementation class need to take care of the the dependencies during startup. Also it is possible that the MSC threads are blocked by such initializations and other subsystems are not started until the cache initialization fails. It should be possible to set a dependency with the store configuration. Example configuration: <replicated-cache name="cache" mode="ASYNC" start="EAGER"> <expiration interval = "300000" lifespan="525600000000"/> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false"/> <transaction mode="NONE"/> <store class="org.jboss.loaders.jdbc.stringbased.CustomJdbcStringBasedCacheStore" passivation="false" preload="true" purge="false" shared="true"> <property name="connectionFactoryClass">org.infinispan.loaders.jdbc.connectionfactory.ManagedConnectionFactory</property> <property name="datasourceJndiLocation">java:jboss/datasources/OracleDS</property> <property name="databaseType">ORACLE</property> ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4063) Remove 5.2.x compatibility code from master

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4063?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4063: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove 5.2.x compatibility code from master > ------------------------------------------- > > Key: ISPN-4063 > URL: https://issues.jboss.org/browse/ISPN-4063 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > All compatibility code with 5.2.x needs to be removed from master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4109) Document API changes for Infinispan 7 Upgrade guide

by William Burns (JIRA)

William Burns created ISPN-4109: ----------------------------------- Summary: Document API changes for Infinispan 7 Upgrade guide Key: ISPN-4109 URL: https://issues.jboss.org/browse/ISPN-4109 Project: Infinispan Issue Type: Enhancement Reporter: William Burns Assignee: William Burns Fix For: 7.0.0.Final Need to update http://infinispan.org/docs/7.0.x/upgrading/upgrading.html to reference the updates classes that I mention in the mailing list: http://lists.jboss.org/pipermail/infinispan-dev/2014-March/014749.html This is assuming these changes make it in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4097) Add SKIP_CACHE_LOAD flag for Hot Rod

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4097?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4097: -------------------------------- Labels: 630 (was: ) > Add SKIP_CACHE_LOAD flag for Hot Rod > ------------------------------------ > > Key: ISPN-4097 > URL: https://issues.jboss.org/browse/ISPN-4097 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Labels: 630 > Fix For: 7.0.0.Final, 7.0.0.Alpha3 > > > Add SKIP_CACHE_LOAD flag to Hot Rod protocol to allow for data to be not be loaded from the cache store. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4085) Random failures in StateProviderTest due to race condition

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4085?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4085: ----------------------------------- Assignee: Gustavo Fernandes (was: Dan Berindei) > Random failures in StateProviderTest due to race condition > ---------------------------------------------------------- > > Key: ISPN-4085 > URL: https://issues.jboss.org/browse/ISPN-4085 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha1 > Environment: jgroups.bind_addr = 127.0.0.1 > java.runtime.version = 1.7.0_51-b13 > java.runtime.name =Java(TM) SE Runtime Environment > java.vm.version = 24.51-b03 > java.vm.vendor = Oracle Corporation > os.name = Mac OS X > os.version = 10.9.2 > sun.arch.data.model = 64 > sun.cpu.endian = little > protocol.stack = null > infinispan.test.jgroups.protocol = tcp > infinispan.unsafe.allow_jdk8_chm = true > java.net.preferIPv4Stack = true > java.net.preferIPv6Stack = null > log4.configuration = null > MAVEN_OPTS = null > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > In my environment the StateProviderTest .test2() fails sometimes (about 10% of the time) with the following error(s): > {code} > Tests run: 4233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 428.06 sec <<< FAILURE! > test2(org.infinispan.statetransfer.StateProviderTest) Time elapsed: 0.042 sec <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at org.infinispan.statetransfer.StateProviderTest.test2(StateProviderTest.java:316) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > {code} > The reason why is that test2() feeds the StateProvider a ThreadPoolExecutorService to execute a OutboundTransfer task asynchronously and right after forcing a state transfer > asserts that there is a StateTransfer in progress. Sometimes the executor service manages to execute the task and as a result it clear the ‘transfersByDestination’ map, and thus the test cannot assert that the state transfer is happening > OTOH, the method test1() never fails because it users a mock executor service which never executes the task, so the state transfer map will always contain the outbound task after initiating the state transfer and thus always visible from outside > The quick fix is to also use a mock executor test for the test2() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4085) Random failures in StateProviderTest due to race condition

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4085?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-4085. ------------------------------------ Fix Version/s: 7.0.0.Final 7.0.0.Alpha2 Resolution: Done > Random failures in StateProviderTest due to race condition > ---------------------------------------------------------- > > Key: ISPN-4085 > URL: https://issues.jboss.org/browse/ISPN-4085 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha1 > Environment: jgroups.bind_addr = 127.0.0.1 > java.runtime.version = 1.7.0_51-b13 > java.runtime.name =Java(TM) SE Runtime Environment > java.vm.version = 24.51-b03 > java.vm.vendor = Oracle Corporation > os.name = Mac OS X > os.version = 10.9.2 > sun.arch.data.model = 64 > sun.cpu.endian = little > protocol.stack = null > infinispan.test.jgroups.protocol = tcp > infinispan.unsafe.allow_jdk8_chm = true > java.net.preferIPv4Stack = true > java.net.preferIPv6Stack = null > log4.configuration = null > MAVEN_OPTS = null > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > In my environment the StateProviderTest .test2() fails sometimes (about 10% of the time) with the following error(s): > {code} > Tests run: 4233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 428.06 sec <<< FAILURE! > test2(org.infinispan.statetransfer.StateProviderTest) Time elapsed: 0.042 sec <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at org.infinispan.statetransfer.StateProviderTest.test2(StateProviderTest.java:316) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > {code} > The reason why is that test2() feeds the StateProvider a ThreadPoolExecutorService to execute a OutboundTransfer task asynchronously and right after forcing a state transfer > asserts that there is a StateTransfer in progress. Sometimes the executor service manages to execute the task and as a result it clear the ‘transfersByDestination’ map, and thus the test cannot assert that the state transfer is happening > OTOH, the method test1() never fails because it users a mock executor service which never executes the task, so the state transfer map will always contain the outbound task after initiating the state transfer and thus always visible from outside > The quick fix is to also use a mock executor test for the test2() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4010) Allow configuring the LevelDB cache store through JON

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4010?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4010: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow configuring the LevelDB cache store through JON > ----------------------------------------------------- > > Key: ISPN-4010 > URL: https://issues.jboss.org/browse/ISPN-4010 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: William Burns > Labels: 621, 630 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > Although a JON console can create a cache, the JON can not set a levelDB store configuration. Our customer wants to set a levelDB store setting using the JON when creating the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4108) Pessimistic tx for a union CH will not be forwarded to all owners.

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/ISPN-4108?page=com.atlassian.jira.plugin.... ] Erik Salter updated ISPN-4108: ------------------------------ Description: There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. If the transactions begin on the old primary owner after the tx list was sent to the new owner, the lock information may not be replicated to the joiner because the originator is still the primary owner in the union CH that we use during state transfer. When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency. We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner when there is a state transfer in progress. was: There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. If the transactions begin on the old primary owner after the tx list was sent to the new owner, the replicate the lock information to the joiner (because the originator is still the primary owner in the union CH that we use during state transfer). When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner, when there is a state transfer in progress. > Pessimistic tx for a union CH will not be forwarded to all owners. > ------------------------------------------------------------------ > > Key: ISPN-4108 > URL: https://issues.jboss.org/browse/ISPN-4108 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > > There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. > If the transactions begin on the old primary owner after the tx list was sent to the new owner, the lock information may not be replicated to the joiner because the originator is still the primary owner in the union CH that we use during state transfer. When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency. > We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner when there is a state transfer in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014