[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8897:
--------------------------------
Fix Version/s: 9.1.7.Final
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: Infinispan
> Issue Type: Bug
> …
[View More]Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Fix For: 9.2.1.Final, 9.1.7.Final
>
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPRK-51) Infinispan 9.2.0.CR1 cause failures in the StreamingSuite
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPRK-51?page=com.atlassian.jira.plugin.s... ]
Gustavo Fernandes resolved ISPRK-51.
------------------------------------
Resolution: Out of Date
The same failures does not have on later versions
> Infinispan 9.2.0.CR1 cause failures in the StreamingSuite
> ---------------------------------------------------------
>
> Key: ISPRK-51
> URL: https://issues.jboss.org/browse/ISPRK-51
> Project: …
[View More]Infinispan Spark
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 0.7
>
>
> Always reproducible:
> {noformat}
> 2018-02-15 11:03:44 [dispatcher-event-loop-3] ERROR ReceiverTracker:70 - Deregistered receiver for stream 0: Stopped by driver
> [info] - test stream producer *** FAILED ***
> [info] java.lang.Exception: Timeout waiting for condition.
> [info] at org.infinispan.spark.test.TestingUtil$.waitForCondition$1(TestingUtil.scala:22)
> [info] at org.infinispan.spark.test.TestingUtil$.waitForCondition(TestingUtil.scala:27)
> [info] at org.infinispan.spark.test.TestingUtil$.waitForCondition(TestingUtil.scala:30)
> [info] at org.infinispan.spark.suites.StreamingSuite$$anonfun$2.apply$mcV$sp(StreamingSuite.scala:76)
> [info] at org.infinispan.spark.suites.StreamingSuite$$anonfun$2.apply(StreamingSuite.scala:56)
> [info] at org.infinispan.spark.suites.StreamingSuite$$anonfun$2.apply(StreamingSuite.scala:56)
> [info] at org.scalatest.Transformer$$anonfun$apply$1.apply$mcV$sp(Transformer.scala:22)
> [info] at org.scalatest.OutcomeOf$class.outcomeOf(OutcomeOf.scala:85)
> [info] at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
> [info] at org.scalatest.Transformer.apply(Transformer.scala:22)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8897:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: …
[View More]Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Fix For: 9.2.1.Final
>
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8904) Indexes from different caches are mixed-up in server mode
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created ISPN-8904:
--------------------------------------
Summary: Indexes from different caches are mixed-up in server mode
Key: ISPN-8904
URL: https://issues.jboss.org/browse/ISPN-8904
Project: Infinispan
Issue Type: Bug
Components: Remote Querying
Affects Versions: 9.1.6.Final, 9.2.0.Final
Reporter: Wolf-Dieter Fink
Assignee: Adrian Nistor
Fix For: 9.2.1.…
[View More]Final
When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
{code:java}
remoteCache1.put(1, entity1)
remoteCache2.put(1, entity2)
{code}
The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8903:
-------------------------------
Description:
The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{C\}. P1 continues to operate and update cache entries, however P2 …
[View More]makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
was:
The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
Consider a cluster {A,B} which partitions into P1 {A} and P2 {C}. P1 continues to operate and update cache entries, however P2 makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> Conflict resolution not initiated if node rejoins with same topology
> --------------------------------------------------------------------
>
> Key: ISPN-8903
> URL: https://issues.jboss.org/browse/ISPN-8903
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Final, 9.2.1.Final
>
>
> The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
> Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{C\}. P1 continues to operate and update cache entries, however P2 makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-8903:
----------------------------------
Summary: Conflict resolution not initiated if node rejoins with same topology
Key: ISPN-8903
URL: https://issues.jboss.org/browse/ISPN-8903
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.0.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 9.3.0.Final, 9.2.1.Final
The …
[View More]current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
Consider a cluster {A,B} which partitions into P1 {A} and P2 {C}. P1 continues to operate and update cache entries, however P2 makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8896) HTTP/2 support is broken
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-8896?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-8896:
-------------------------------------------
This commit broke it:
{code}
commit c268f9cf518cd8603fbafc001b6c92c72d34ecff
Author: Sebastian Laskawiec <slaskawi(a)redhat.com>
Date: Mon Jan 15 13:53:17 2018 +0100
ISPN-8657 Netty upgrade to 4.1.21
{code}
> HTTP/2 support is broken
> ------------------------
>
> Key: ISPN-8896
> …
[View More] URL: https://issues.jboss.org/browse/ISPN-8896
> Project: Infinispan
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.2.0.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
> CURL reports that HTTP Settings frame is broken:
> On Terminal 1:
> {code}
> docker run -e "APP_USER=test" -e "APP_PASS=test" jboss/infinispan-server:9.2.0.Final ../../docs/examples/configs/standalone-rest-ssl.xml
> {code}
> On Terminal 2:
> {code}
> curl "Accept: text/plain" -k -v --http2 -u test:test https://172.17.0.2:8443/rest/default/test
> * Illegal port number
> * Closing connection -1
> curl: (3) Illegal port number
> * Trying 172.17.0.2...
> * TCP_NODELAY set
> * Connected to 172.17.0.2 (172.17.0.2) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * skipping SSL peer certificate verification
> * ALPN, server accepted to use h2
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> * Server certificate:
> * subject: CN=localhost
> * start date: Mar 01 12:02:32 2018 GMT
> * expire date: Feb 27 12:02:32 2028 GMT
> * common name: localhost
> * issuer: CN=localhost
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
> * Server auth using Basic with user 'test'
> * Using Stream ID: 1 (easy handle 0x55972b0700d0)
> > GET /rest/default/test HTTP/2
> > Host: 172.17.0.2:8443
> > Authorization: Basic dGVzdDp0ZXN0
> > User-Agent: curl/7.53.1
> > Accept: */*
> >
> * http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly.
> * Closing connection 0
> curl: (16) Illegal port number
> {code}
> The same with 9.1.5.Final:
> {code}
> curl -d test -H "Accept: text/plain" -k -v --http2 -u test:test https://172.17.0.2:8443/rest/default/test
> * Trying 172.17.0.2...
> * TCP_NODELAY set
> * Connected to 172.17.0.2 (172.17.0.2) port 8443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * skipping SSL peer certificate verification
> * ALPN, server accepted to use h2
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> * Server certificate:
> * subject: CN=localhost
> * start date: Mar 01 12:04:47 2018 GMT
> * expire date: Feb 27 12:04:47 2028 GMT
> * common name: localhost
> * issuer: CN=localhost
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
> * Server auth using Basic with user 'test'
> * Using Stream ID: 1 (easy handle 0x555cd62630d0)
> > POST /rest/default/test HTTP/2
> > Host: 172.17.0.2:8443
> > Authorization: Basic dGVzdDp0ZXN0
> > User-Agent: curl/7.53.1
> > Accept: text/plain
> > Content-Length: 4
> > Content-Type: application/x-www-form-urlencoded
> >
> * We are completely uploaded and fine
> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
> < HTTP/2 200
> < etag: application/x-www-form-urlencoded-235262424
> < content-type: text/plain
> < content-length: 0
> <
> * Connection #0 to host 172.17.0.2 left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years
[JBoss JIRA] (ISPN-8895) InfinispanDefaultCacheFactoryBeanContextTest fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8895?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8895:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> InfinispanDefaultCacheFactoryBeanContextTest fails
> --------------------------------------------------
>
> Key: ISPN-8895
> URL: https://issues.jboss.org/browse/ISPN-8895
> Project: Infinispan
> Issue …
[View More]Type: Bug
> Components: Spring Integration, Test Suite - Core
> Affects Versions: 9.2.0.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.1.Final
>
>
> Error Message
> Failed to load ApplicationContext
> Stacktrace
> java.lang.IllegalStateException: Failed to load ApplicationContext
> at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:124)
> at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:83)
> at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:117)
> at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:83)
> at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:230)
> at org.springframework.test.context.testng.AbstractTestNGSpringContextTests.springTestContextPrepareTestInstance(AbstractTestNGSpringContextTests.java:149)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'infinispanCacheContainer' defined in class path resource [org/infinispan/spring/support/embedded/InfinispanDefaultCacheFactoryBeanContextTest.xml]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.infinispan.manager.EmbeddedCacheManager]: Factory method 'createCacheManager' threw exception; nested exception is java.lang.IllegalStateException: Test name is not set! Please call TestResourceTracker.testThreadStarted(this) in thread testng-InfinispanNamedEmbeddedCacheFactoryBeanTest !
> at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:599)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1128)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1022)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:512)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:754)
> at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:866)
> at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:542)
> at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:128)
> at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:60)
> at org.springframework.test.context.support.AbstractDelegatingSmartContextLoader.delegateLoading(AbstractDelegatingSmartContextLoader.java:108)
> at org.springframework.test.context.support.AbstractDelegatingSmartContextLoader.loadContext(AbstractDelegatingSmartContextLoader.java:251)
> at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
> at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
> ... 25 more
> Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.infinispan.manager.EmbeddedCacheManager]: Factory method 'createCacheManager' threw exception; nested exception is java.lang.IllegalStateException: Test name is not set! Please call TestResourceTracker.testThreadStarted(this) in thread testng-InfinispanNamedEmbeddedCacheFactoryBeanTest !
> at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:189)
> at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:588)
> ... 42 more
> Caused by: java.lang.IllegalStateException: Test name is not set! Please call TestResourceTracker.testThreadStarted(this) in thread testng-InfinispanNamedEmbeddedCacheFactoryBeanTest !
> at org.infinispan.test.fwk.TestResourceTracker.getCurrentTestName(TestResourceTracker.java:82)
> at org.infinispan.test.fwk.TestResourceTracker.addResource(TestResourceTracker.java:43)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:403)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:72)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:240)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:215)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:219)
> at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
> ... 43 more
> ... Removed 20 stack frames
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
[View Less]
7 years