[JBoss JIRA] (ISPN-11410) Upgrade console 0.4.Final
by Katia Aresti (Jira)
Katia Aresti created ISPN-11410:
-----------------------------------
Summary: Upgrade console 0.4.Final
Key: ISPN-11410
URL: https://issues.redhat.com/browse/ISPN-11410
Project: Infinispan
Issue Type: Component Upgrade
Components: Console
Affects Versions: 10.1.3.Final
Reporter: Katia Aresti
Assignee: Katia Aresti
upgrade to 0.4.Final
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ISPN-11409) Integration tests for examples
by Katia Aresti (Jira)
Katia Aresti created ISPN-11409:
-----------------------------------
Summary: Integration tests for examples
Key: ISPN-11409
URL: https://issues.redhat.com/browse/ISPN-11409
Project: Infinispan
Issue Type: Component Upgrade
Components: Quarkus, Spring Integration
Affects Versions: 10.1.3.Final
Reporter: Katia Aresti
Assignee: Katia Aresti
Today Infinispan Server needs to be run or use all the dependencies we have in the test jars to create one programatically.
With the latest infinispan-server and test-containers, add integration tests for Quarkus and Spring-Boot
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ISPN-11367) getCache(name) should never use the default cache's configuration
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11367?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11367:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7974
> getCache(name) should never use the default cache's configuration
> -----------------------------------------------------------------
>
> Key: ISPN-11367
> URL: https://issues.redhat.com/browse/ISPN-11367
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 10.1.2.Final, 11.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Alpha2
>
>
> {{DefaultCacheManager.getCache(name)}} will try to create the cache if it doesn't exist, and if a matching configuration doesn't exist either it uses the default cache's configuration.
> Since 9.0 named cache configurations no longer inherit from the default cache configuration, so using the default cache's configuration as a default configuration is surprising.
> {{DefaultCacheManager.getCache(name)}} should only create the cache if a matching configuration exists, otherwise it should throw an exception.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (ISPN-11373) XSite backup commands should be sent from a blocking thread
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11373?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11373:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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: 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)
5 years