March 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11455) TestingUtil.waitForNoRebalanceAcrossManagers: skip create internal caches

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-11455: ---------------------------------- Summary: TestingUtil.waitForNoRebalanceAcrossManagers: skip create internal caches Key: ISPN-11455 URL: https://issues.redhat.com/browse/ISPN-11455 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 11.0.0.Alpha2, 10.1.3.Final Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 10.1.4.Final, 11.0.0.Dev03 {{TestingUtil.waitForNoRebalanceAcrossManagers()}} lookups all caches (including internal) to make sure no rebalance is in progress. However, it is starting the internal caches while it isn't needed. It is the case for the counter's cache: {noformat} java.lang.RuntimeException: Cache org.infinispan.COUNTER timed out waiting for rebalancing to complete on node HotRodMergeTest-NodeA-42156, expected member list is [HotRodMergeTest-NodeA-42156, HotRodMergeTest-NodeB-64259], current member list is [HotRodMergeTest-NodeB-64259]! at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:429) at org.infinispan.test.TestingUtil.waitForNoRebalanceAcrossManagers(TestingUtil.java:449) at org.infinispan.server.hotrod.HotRodMergeTest.testNewTopologySentAfterOverlappingMerge(HotRodMergeTest.java:114) {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11351) Getting details of the protobuf cache returns error

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11351?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11351: ------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8030 > Getting details of the protobuf cache returns error > --------------------------------------------------- > > Key: ISPN-11351 > URL: https://issues.redhat.com/browse/ISPN-11351 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > http://localhost:11222/rest/v2/caches/___protobuf_metadata > ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true > It happens for XML and JSON serializers -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11351) Getting details of the protobuf cache returns error

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11351?page=com.atlassian.jira.plugi... ] Work on ISPN-11351 started by Gustavo Fernandes. ------------------------------------------------ > Getting details of the protobuf cache returns error > --------------------------------------------------- > > Key: ISPN-11351 > URL: https://issues.redhat.com/browse/ISPN-11351 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > http://localhost:11222/rest/v2/caches/___protobuf_metadata > ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true > It happens for XML and JSON serializers -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11351) Getting details of the protobuf cache returns error

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11351?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11351: ------------------------------------- Status: Open (was: New) > Getting details of the protobuf cache returns error > --------------------------------------------------- > > Key: ISPN-11351 > URL: https://issues.redhat.com/browse/ISPN-11351 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > http://localhost:11222/rest/v2/caches/___protobuf_metadata > ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true > It happens for XML and JSON serializers -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10270) DroppedConnectionsTest.testClosedConnection random failures

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10270?page=com.atlassian.jira.plugi... ] Tristan Tarrant edited comment on ISPN-10270 at 3/11/20 6:22 AM: ----------------------------------------------------------------- The test is relying on old (pre-netty) client behaviour, where closing a channel was synchronous. In Netty this is asynchronous, which causes out-of-order issues (which are much more realistic) Also, the client makes certain assertions based on wrong assumptions: * RetryOnFailureOperation asserts that a channel must be active when invoking an operation. It does this outside of the try/catch/finally logic. If the channel is closed unexpectedly, the assertion fails but doesn't release the channel. * ChannelPool claims that protection against concurrent releases is fine, but then has an assertion which fails when decrementing created connections below 0. was (Author: nadirx): The test is relying on old (pre-netty) client behaviour, where closing a channel was synchronous. In Netty this is asynchronous, which causes out-of-order issues. Also, the client makes certain assertions based on wrong assumptions: * RetryOnFailureOperation asserts that a channel must be active when invoking an operation. It does this outside of the try/catch/finally logic. If the channel is closed unexpectedly, the assertion fails but doesn't release the channel. * ChannelPool claims that protection against concurrent releases is fine, but then has an assertion which fails when decrementing created connections below 0. > DroppedConnectionsTest.testClosedConnection random failures > ----------------------------------------------------------- > > Key: ISPN-10270 > URL: https://issues.redhat.com/browse/ISPN-10270 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Priority: Major > Labels: testsuite_stability > Attachments: ISPN-10137_Injection_without_reflection_20190605-1157_DroppedConnectionsTest-infinispan-client-hotrod.log.gz > > > {noformat} > 12:03:26,084 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection > java.lang.AssertionError: expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.14.3.jar:?] > at org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection(DroppedConnectionsTest.java:78) ~[test-classes/:?] > {noformat} > Full trace log attached -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10270) DroppedConnectionsTest.testClosedConnection random failures

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10270?page=com.atlassian.jira.plugi... ] Tristan Tarrant commented on ISPN-10270: ---------------------------------------- The test is relying on old (pre-netty) client behaviour, where closing a channel was synchronous. In Netty this is asynchronous, which causes out-of-order issues. Also, the client makes certain assertions based on wrong assumptions: * RetryOnFailureOperation asserts that a channel must be active when invoking an operation. It does this outside of the try/catch/finally logic. If the channel is closed unexpectedly, the assertion fails but doesn't release the channel. * ChannelPool claims that protection against concurrent releases is fine, but then has an assertion which fails when decrementing created connections below 0. > DroppedConnectionsTest.testClosedConnection random failures > ----------------------------------------------------------- > > Key: ISPN-10270 > URL: https://issues.redhat.com/browse/ISPN-10270 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.0.0.Beta3 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Priority: Major > Labels: testsuite_stability > Attachments: ISPN-10137_Injection_without_reflection_20190605-1157_DroppedConnectionsTest-infinispan-client-hotrod.log.gz > > > {noformat} > 12:03:26,084 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection > java.lang.AssertionError: expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.14.3.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.14.3.jar:?] > at org.infinispan.client.hotrod.DroppedConnectionsTest.testClosedConnection(DroppedConnectionsTest.java:78) ~[test-classes/:?] > {noformat} > Full trace log attached -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11454) Upgrade 10.1.x.Final the Infinispan Embedded Tutorial

by Katia Aresti (Jira)

Katia Aresti created ISPN-11454: ----------------------------------- Summary: Upgrade 10.1.x.Final the Infinispan Embedded Tutorial Key: ISPN-11454 URL: https://issues.redhat.com/browse/ISPN-11454 Project: Infinispan Issue Type: Task Components: Demos and Tutorials Affects Versions: 10.1.3.Final Reporter: Katia Aresti Assignee: Katia Aresti The documentation in the website for the tutorial is outdated Needs to be reviewed for the latest Infinispan -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11351) Getting details of the protobuf cache returns error

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11351?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11351: ------------------------------------- Description: http://localhost:11222/rest/v2/caches/___protobuf_metadata ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true It happens for XML and JSON serializers was: http://localhost:11222/rest/v2/caches/___protobuf_metadata ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true > Getting details of the protobuf cache returns error > --------------------------------------------------- > > Key: ISPN-11351 > URL: https://issues.redhat.com/browse/ISPN-11351 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > http://localhost:11222/rest/v2/caches/___protobuf_metadata > ISPN000412: Cannot determine a synthetic transaction configuration from mode=TRANSACTIONAL, xaEnabled=true, recoveryEnabled=false, batchingEnabled=true > It happens for XML and JSON serializers -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11446) Always set a default request MediaType for caches

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11446?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11446: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8029 > Always set a default request MediaType for caches > ------------------------------------------------- > > Key: ISPN-11446 > URL: https://issues.redhat.com/browse/ISPN-11446 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 11.0.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > *Background*: when a cache is created, it does not have a default request type inside its internal Key/Value DataConversion objects, so no transcoding will be attempted during its operations. > When decorated with _{{.withMediaType(MediaType key, MediaType value)}}_, a new cache instance is produced setting the request type internally, and all operations will be converted from the storage media type to this request media type (when reading), or from the request media type to storage media type (when writing). > *Drawback*: When a cache is used through any remote endpoint, it is always decorated since remote clients are able to communicate the request format, but when a cache is used directly in the same JVM the request type is _null_, so no transcoding is done, unless the cache is decorated with the required type. > *Change*: This issue will change the default request type for all caches to _{{application/x-java-object}}_, so transcoding can be done in embedded caches without the need to decorate, it's enough to set the storage type in the configuration. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11446) Always set a default request MediaType for caches

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11446?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11446: ------------------------------------- Description: *Background*: when a cache is created, it does not have a default request type inside its internal Key/Value DataConversion objects, so no transcoding will be attempted during its operations. When decorated with _{{.withMediaType(MediaType key, MediaType value)}}_, a new cache instance is produced setting the request type internally, and all operations will be converted from the storage media type to this request media type (when reading), or from the request media type to storage media type (when writing). *Drawback*: When a cache is used through any remote endpoint, it is always decorated since remote clients are able to communicate the request format, but when a cache is used directly in the same JVM the request type is _null_, so no transcoding is done, unless the cache is decorated with the required type. *Change*: This issue will change the default request type for all caches to _{{application/x-java-object}}_, so transcoding can be done in embedded caches without the need to decorate, provided the configuration has a different MediaType than _{{application/x-java-object}}_ was: *Background*: when a cache is created, it does not have a default request type inside its internal Key/Value DataConversion objects, so no transcoding will be attempted during its operations. When decorated with _{{.withMediaType(MediaType key, MediaType value)}}_, a new cache instance is produced setting the request type internally, and all operations will be converted from the storage media type to this request media type (when reading), or from the request media type to storage media type (when writing). *Drawback*: When a cache is used through any remote endpoint, it is always decorated since remote clients are able to communicate the request format, but when a cache is used directly in the same JVM the request type is _null_, so no transcoding is done, unless the cache is decorated with the required type. *Change*: This issue will change the default request type for all caches to _{{application/x-java-object}}_, so transcoding can be done in embedded caches without the need to decorate, it's enough to set the storage type in the configuration. > Always set a default request MediaType for caches > ------------------------------------------------- > > Key: ISPN-11446 > URL: https://issues.redhat.com/browse/ISPN-11446 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 11.0.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > *Background*: when a cache is created, it does not have a default request type inside its internal Key/Value DataConversion objects, so no transcoding will be attempted during its operations. > When decorated with _{{.withMediaType(MediaType key, MediaType value)}}_, a new cache instance is produced setting the request type internally, and all operations will be converted from the storage media type to this request media type (when reading), or from the request media type to storage media type (when writing). > *Drawback*: When a cache is used through any remote endpoint, it is always decorated since remote clients are able to communicate the request format, but when a cache is used directly in the same JVM the request type is _null_, so no transcoding is done, unless the cache is decorated with the required type. > *Change*: This issue will change the default request type for all caches to _{{application/x-java-object}}_, so transcoding can be done in embedded caches without the need to decorate, provided the configuration has a different MediaType than _{{application/x-java-object}}_ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 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 2020