February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-11334) Document do not change context-path for the rest connector

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11334?page=com.atlassian.jira.plugi... ] Gustavo Fernandes commented on ISPN-11334: ------------------------------------------ Merged to master > Document do not change context-path for the rest connector > ---------------------------------------------------------- > > Key: ISPN-11334 > URL: https://issues.redhat.com/browse/ISPN-11334 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > Fix For: 11.0.0.Alpha2 > > > context-path should not be configurable for REST connectors -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11334) Document do not change context-path for the rest connector

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11334?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11334: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7930 > Document do not change context-path for the rest connector > ---------------------------------------------------------- > > Key: ISPN-11334 > URL: https://issues.redhat.com/browse/ISPN-11334 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > > context-path should not be configurable for REST connectors -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11334) Document do not change context-path for the rest connector

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11334?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11334: ------------------------------- Status: Open (was: New) > Document do not change context-path for the rest connector > ---------------------------------------------------------- > > Key: ISPN-11334 > URL: https://issues.redhat.com/browse/ISPN-11334 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > > context-path should not be configurable for REST connectors -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10539) Server Logging management via REST

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10539?page=com.atlassian.jira.plugi... ] Tristan Tarrant reassigned ISPN-10539: -------------------------------------- Assignee: Tristan Tarrant (was: Gustavo Fernandes) > Server Logging management via REST > ---------------------------------- > > Key: ISPN-10539 > URL: https://issues.redhat.com/browse/ISPN-10539 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Tristan Tarrant > Priority: Major > > Interact with the Log4j instance -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11373) XSite backup commands should be sent from a blocking thread

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11373?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11373: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7929 > XSite backup commands should be sent from a blocking thread > ----------------------------------------------------------- > > Key: ISPN-11373 > URL: https://issues.redhat.com/browse/ISPN-11373 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > XSite backup commands usually need more processing on the receiving site than local cluster commands do on the receiving node, which means there's a much higher chance of {{channel.send(message)}} to block. > {{UFC}}, {{UFC_NB}}, {{MFC}} and {{MFC_NB}} all block when there are not enough credits. > The _NB variants have an additional queue as a safety net, but that only delays the blocking: it's the same as increasing {{max_credits}} by {{max_queue_size}}, except with less work for {{UNICAST3}}/{{NAKACK2}}. > {{TCP}} and {{UDP}} also block if their send buffer is full. Using a bundler like {{transfer-queue}} instead of the default {{no-bundler}} will only delay the blocking until the bundler's queue is also full. > The biggest problem is when xsite backup commands are sent from a jgroups thread, and {{channel.send(message)}} blocks the thread. If the jgroups thread pool becomes full, it cannot process more messages, not even responses from the remote site. > JGroups creates temporary threads to process internal messages when its thread pool is full, but not even that can help when the other nodes' thread pools are also full: > {noformat} > "jgroups-temp-thread-5728,_ma267mlvjdg015:dal_mcom_perf" #11443 prio=5 os_prio=0 tid=0x000000000906f800 nid=0x26cb waiting on condition [0x00007fb0b7b0a000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005f3bce048> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353) > at org.jgroups.protocols.TransferQueueBundler.send(TransferQueueBundler.java:97) > at org.jgroups.protocols.TP.send(TP.java:1441) > at org.jgroups.protocols.TP._send(TP.java:1195) > at org.jgroups.protocols.TP.down(TP.java:1111) > ... > at org.jgroups.protocols.FlowControl.sendCredit(FlowControl.java:480) > at org.jgroups.protocols.FlowControl.handleCreditRequest(FlowControl.java:469) > at org.jgroups.protocols.FlowControl.handleUpEvent(FlowControl.java:379) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:350) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10212) StoreMigrator Docs should detail both jar and maven approaches

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10212?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-10212: ------------------------------- Sprint: (was: DataGrid Sprint #40) > StoreMigrator Docs should detail both jar and maven approaches > -------------------------------------------------------------- > > Key: ISPN-10212 > URL: https://issues.redhat.com/browse/ISPN-10212 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 10.0.0.Beta3 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > > The StoreMigrator docs are not clear about how to use the migrator with either a jar or maven approach, instead it currently confuses both approaches. The docs should be re-written so that the standalone jar approach is explained, before detailing how to utilise the tool via maven. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11373) XSite backup commands should be sent from a blocking thread

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11373?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11373: -------------------------------- Status: Open (was: New) > XSite backup commands should be sent from a blocking thread > ----------------------------------------------------------- > > Key: ISPN-11373 > URL: https://issues.redhat.com/browse/ISPN-11373 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final > > > XSite backup commands usually need more processing on the receiving site than local cluster commands do on the receiving node, which means there's a much higher chance of {{channel.send(message)}} to block. > {{UFC}}, {{UFC_NB}}, {{MFC}} and {{MFC_NB}} all block when there are not enough credits. > The _NB variants have an additional queue as a safety net, but that only delays the blocking: it's the same as increasing {{max_credits}} by {{max_queue_size}}, except with less work for {{UNICAST3}}/{{NAKACK2}}. > {{TCP}} and {{UDP}} also block if their send buffer is full. Using a bundler like {{transfer-queue}} instead of the default {{no-bundler}} will only delay the blocking until the bundler's queue is also full. > The biggest problem is when xsite backup commands are sent from a jgroups thread, and {{channel.send(message)}} blocks the thread. If the jgroups thread pool becomes full, it cannot process more messages, not even responses from the remote site. > JGroups creates temporary threads to process internal messages when its thread pool is full, but not even that can help when the other nodes' thread pools are also full: > {noformat} > "jgroups-temp-thread-5728,_ma267mlvjdg015:dal_mcom_perf" #11443 prio=5 os_prio=0 tid=0x000000000906f800 nid=0x26cb waiting on condition [0x00007fb0b7b0a000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005f3bce048> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353) > at org.jgroups.protocols.TransferQueueBundler.send(TransferQueueBundler.java:97) > at org.jgroups.protocols.TP.send(TP.java:1441) > at org.jgroups.protocols.TP._send(TP.java:1195) > at org.jgroups.protocols.TP.down(TP.java:1111) > ... > at org.jgroups.protocols.FlowControl.sendCredit(FlowControl.java:480) > at org.jgroups.protocols.FlowControl.handleCreditRequest(FlowControl.java:469) > at org.jgroups.protocols.FlowControl.handleUpEvent(FlowControl.java:379) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:350) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-11373) XSite backup commands should be sent from a blocking thread

by Dan Berindei (Jira)

Dan Berindei created ISPN-11373: ----------------------------------- Summary: XSite backup commands should be sent from a blocking thread Key: ISPN-11373 URL: https://issues.redhat.com/browse/ISPN-11373 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 11.0.0.Alpha1, 10.1.2.Final, 9.4.18.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final XSite backup commands usually need more processing on the receiving site than local cluster commands do on the receiving node, which means there's a much higher chance of {{channel.send(message)}} to block. {{UFC}}, {{UFC_NB}}, {{MFC}} and {{MFC_NB}} all block when there are not enough credits. The _NB variants have an additional queue as a safety net, but that only delays the blocking: it's the same as increasing {{max_credits}} by {{max_queue_size}}, except with less work for {{UNICAST3}}/{{NAKACK2}}. {{TCP}} and {{UDP}} also block if their send buffer is full. Using a bundler like {{transfer-queue}} instead of the default {{no-bundler}} will only delay the blocking until the bundler's queue is also full. The biggest problem is when xsite backup commands are sent from a jgroups thread, and {{channel.send(message)}} blocks the thread. If the jgroups thread pool becomes full, it cannot process more messages, not even responses from the remote site. JGroups creates temporary threads to process internal messages when its thread pool is full, but not even that can help when the other nodes' thread pools are also full: {noformat} "jgroups-temp-thread-5728,_ma267mlvjdg015:dal_mcom_perf" #11443 prio=5 os_prio=0 tid=0x000000000906f800 nid=0x26cb waiting on condition [0x00007fb0b7b0a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000005f3bce048> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353) at org.jgroups.protocols.TransferQueueBundler.send(TransferQueueBundler.java:97) at org.jgroups.protocols.TP.send(TP.java:1441) at org.jgroups.protocols.TP._send(TP.java:1195) at org.jgroups.protocols.TP.down(TP.java:1111) ... at org.jgroups.protocols.FlowControl.sendCredit(FlowControl.java:480) at org.jgroups.protocols.FlowControl.handleCreditRequest(FlowControl.java:469) at org.jgroups.protocols.FlowControl.handleUpEvent(FlowControl.java:379) at org.jgroups.protocols.FlowControl.up(FlowControl.java:350) {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9814) Convert DistributedStreams to use Distributed Publisher for streaming response

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-9814?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-9814: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7928 > Convert DistributedStreams to use Distributed Publisher for streaming response > ------------------------------------------------------------------------------ > > Key: ISPN-9814 > URL: https://issues.redhat.com/browse/ISPN-9814 > Project: Infinispan > Issue Type: Sub-task > Components: Publisher, Streams > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha2 > > > After ISPN-9812 is complete we should be able to convert DistributedCacheStream#iterator method over to using Publisher. We _should_ be able to implement forEach as well possibly, but unclear. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9814) Convert DistributedStreams to use Distributed Publisher for streaming response

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-9814?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-9814: ----------------------------- Fix Version/s: 11.0.0.Alpha2 > Convert DistributedStreams to use Distributed Publisher for streaming response > ------------------------------------------------------------------------------ > > Key: ISPN-9814 > URL: https://issues.redhat.com/browse/ISPN-9814 > Project: Infinispan > Issue Type: Sub-task > Components: Publisher, Streams > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Alpha2 > > > After ISPN-9812 is complete we should be able to convert DistributedCacheStream#iterator method over to using Publisher. We _should_ be able to implement forEach as well possibly, but unclear. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2020