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