October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10824) Hanged tests are ignored by Jenkins

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10824?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10824: -------------------------------- Status: Open (was: New) > Hanged tests are ignored by Jenkins > ----------------------------------- > > Key: ISPN-10824 > URL: https://issues.jboss.org/browse/ISPN-10824 > Project: Infinispan > Issue Type: Bug > Components: Build, Test Suite - Core > Affects Versions: 9.4.16.Final, 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > ISPN-10161 was supposed to add a custom JUnit report in {{RunningTestsRegistry}} just before killing the JVM. Unfortunately it only calls {{TestSuiteProgress.fakeTestFailure()}}, which sounds like it should do it, but actually only writes a {{Test failed:}} messsage to the console, which Jenkins ignores. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10824) Hanged tests are ignored by Jenkins

by Dan Berindei (Jira)

Dan Berindei created ISPN-10824: ----------------------------------- Summary: Hanged tests are ignored by Jenkins Key: ISPN-10824 URL: https://issues.jboss.org/browse/ISPN-10824 Project: Infinispan Issue Type: Bug Components: Build, Test Suite - Core Affects Versions: 10.0.0.CR3, 9.4.16.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.0.0.Final, 9.4.17.Final ISPN-10161 was supposed to add a custom JUnit report in {{RunningTestsRegistry}} just before killing the JVM. Unfortunately it only calls {{TestSuiteProgress.fakeTestFailure()}}, which sounds like it should do it, but actually only writes a {{Test failed:}} messsage to the console, which Jenkins ignores. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10663?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10663: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-10663 > URL: https://issues.jboss.org/browse/ISPN-10663 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10818) Remote-query 9.4.x backwards compatibility

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10818?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10818: --------------------------------- Status: Open (was: New) > Remote-query 9.4.x backwards compatibility > ------------------------------------------ > > Key: ISPN-10818 > URL: https://issues.jboss.org/browse/ISPN-10818 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 10.0.0.CR3 > Reporter: Ryan Emerson > Priority: Major > > For performance reasons, ProtoStream changed the TypeId of WrappedMessage to 0, which means that pre 10.x clients using RemoteQuery are no longer compatible. Furthermore, ISPN-10663 updated the TypeId of the remote query messages to conform to the Infinispan TypeId ranges defined in ProtoStreamTypeIds. > Therefore, for pre 10.x clients, it is neccessary for all remote query requests to have the legacy TypeId mapped to the new TypeId values. https://issues.jboss.org/browse/IPROTO-119 introduced a mechanism for this mapping, however more work is required, as the mapping must occur on a per request/response basis (only if communication is with a legacy client). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10823) Cache not found on put after create was successful

by Galder Zamarreño (Jira)

Galder Zamarreño created ISPN-10823: --------------------------------------- Summary: Cache not found on put after create was successful Key: ISPN-10823 URL: https://issues.jboss.org/browse/ISPN-10823 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 10.0.0.CR3 Reporter: Galder Zamarreño During x-site testing of 10.0.0.CR3, a situation came up where a script successfully created remote caches in both sites being tested, but then a cache put in one of the sites returns 404. After a few calls, the site returned 200. Command line output can be found [here|https://gist.github.com/galderz/a98a5dd42ed77a0be798ab8e3239053c]. In the test, each site contains 2 nodes. The manual test is being added by [this operator PR|https://github.com/infinispan/infinispan-operator/pull/185]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10822) java.lang.Error: Maximum permit count exceeded

by AshokKumar NV (Jira)

AshokKumar NV created ISPN-10822: ------------------------------------ Summary: java.lang.Error: Maximum permit count exceeded Key: ISPN-10822 URL: https://issues.jboss.org/browse/ISPN-10822 Project: Infinispan Issue Type: Bug Components: Clustered Executor Affects Versions: 9.4.4.Final Reporter: AshokKumar NV We use an MS-SQL database when we are try to retrieve the data concurrently we are facing this issue. Please find the stack trace. {noformat} java.lang.Error: Maximum permit count exceeded at java.base/java.util.concurrent.Semaphore$Sync.tryReleaseShared(Semaphore.java:198) at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1382) at java.base/java.util.concurrent.Semaphore.release(Semaphore.java:432) at io.reactivex.internal.operators.flowable.FlowableUsing$UsingSubscriber.onComplete(FlowableUsing.java:139) at io.reactivex.internal.operators.flowable.FlowableUsing$UsingSubscriber.onComplete(FlowableUsing.java:148) at io.reactivex.internal.subscriptions.EmptySubscription.complete(EmptySubscription.java:68) at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribe(FlowableFromIterable.java:61) at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribeActual(FlowableFromIterable.java:47) at io.reactivex.Flowable.subscribe(Flowable.java:14409) at io.reactivex.Flowable.subscribe(Flowable.java:14356) at io.reactivex.internal.operators.flowable.FlowableUsing.subscribeActual(FlowableUsing.java:74) at io.reactivex.Flowable.subscribe(Flowable.java:14409) at io.reactivex.Flowable.subscribe(Flowable.java:14356) at io.reactivex.internal.operators.flowable.FlowableUsing.subscribeActual(FlowableUsing.java:74) at io.reactivex.Flowable.subscribe(Flowable.java:14409) at io.reactivex.internal.operators.flowable.FlowableMap.subscribeActual(FlowableMap.java:38) at io.reactivex.Flowable.subscribe(Flowable.java:14409) at io.reactivex.internal.operators.flowable.BlockingFlowableIterable.iterator(BlockingFlowableIterable.java:42) at org.infinispan.util.Closeables.iterator(Closeables.java:30) at org.infinispan.stream.impl.local.PersistenceEntryStreamSupplier.lambda$null$5(PersistenceEntryStreamSupplier.java:104) at org.infinispan.util.LazyConcatIterator.hasNext(LazyConcatIterator.java:43) at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1811) at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294) at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206) at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:169) at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300) at java.base/java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10575) Try to replace TEST_PING with LOCAL_PING

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10575?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10575: -------------------------------- Sprint: DataGrid Sprint #35 > Try to replace TEST_PING with LOCAL_PING > ---------------------------------------- > > Key: ISPN-10575 > URL: https://issues.jboss.org/browse/ISPN-10575 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 10.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > JGroups added a {{LOCAL_PING}} protocol (JGRP-2284) that could potentially be used to replace our {{TEST_PING}}, so that we don't depend on {{Discovery}} internals. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10820) Upgrade to JGroups 4.1.6.Final

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10820?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10820: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7485 > Upgrade to JGroups 4.1.6.Final > ------------------------------ > > Key: ISPN-10820 > URL: https://issues.jboss.org/browse/ISPN-10820 > Project: Infinispan > Issue Type: Component Upgrade > Components: Dependency > Affects Versions: 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > [4.1.5.Final|https://issues.jboss.org/projects/JGRP/versions/12342765] added support for UDP and PING on Quarkus and fixed some issues with LOCAL_PING > [4.1.6.Final|https://issues.jboss.org/projects/JGRP/versions/12342864] fixes a recurring warning message from FD_ALL -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10575) Try to replace TEST_PING with LOCAL_PING

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10575?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10575: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7485 > Try to replace TEST_PING with LOCAL_PING > ---------------------------------------- > > Key: ISPN-10575 > URL: https://issues.jboss.org/browse/ISPN-10575 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 10.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > JGroups added a {{LOCAL_PING}} protocol (JGRP-2284) that could potentially be used to replace our {{TEST_PING}}, so that we don't depend on {{Discovery}} internals. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10821) Decrease GMS join_timeout and increase xPING num_discovery_runs

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10821?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10821: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7485 > Decrease GMS join_timeout and increase xPING num_discovery_runs > --------------------------------------------------------------- > > Key: ISPN-10821 > URL: https://issues.jboss.org/browse/ISPN-10821 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 9.4.16.Final, 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > Our default JGroups configurations have a GMS {{join_timeout="5000"}}, meaning the first node to start will always wait for 5 seconds before becoming coordinator. It should be safe to use the JGroups default of 2 seconds. > To make it even more safe, we could configure the discovery protocol's {{num_discovery_runs="3"}}, so that it makes multiple attempts to contact existing nodes during those 2 seconds of waiting. {{num_discovery_runs}} is only used for the initial discovery, so there's no danger of creating additional traffic while the node is up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 October 2019