[JBoss JIRA] (ISPN-11349) lock leak in SIFS FileProvider
by Jonathan Halliday (Jira)
Jonathan Halliday created ISPN-11349:
----------------------------------------
Summary: lock leak in SIFS FileProvider
Key: ISPN-11349
URL: https://issues.redhat.com/browse/ISPN-11349
Project: Infinispan
Issue Type: Bug
Reporter: Jonathan Halliday
SIFS FileProvider clear() method is missing a finally block, so some errors may not release the lock properly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11348) Client requests go to wrong server with binary storage
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created ISPN-11348:
---------------------------------------
Summary: Client requests go to wrong server with binary storage
Key: ISPN-11348
URL: https://issues.redhat.com/browse/ISPN-11348
Project: Infinispan
Issue Type: Bug
Components: Core, Hot Rod, Server
Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Gustavo Fernandes
Fix For: 10.1.3.Final, 11.0.0.Alpha2, 9.4.19.Final
Caches with BINARY storage accept {{byte[]}} keys, but add a prefix to indicate that the input was a {{byte[]}} and not a {{WrappedByteArray}}.
This happens in {{BinaryEncoder.toStorage()}}, before the segment of the key is computed, so the segment computed by the server is different from the segment computed by the client (based on the key without the prefix).
Since the client doesn't know (and shouldn't know) the server cache's storage type, the server should always compute the segment of the key based on the {{byte[]}} sent by the client. The simplest way to achieve that would be to make {{BinaryEncoder}} skip the marshalling for {{byte[]}}.
The only problem is that we don't want users to put in a {{WrappedByteArray}} and get back a {{byte[]}}, so we should disallow {{WrappedByteArray}} keys and values in {{Cache}} methods.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11297) Rejoining nodes with global state may have their caches corrupted if there is a config mismatch
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11297?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11297:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Rejoining nodes with global state may have their caches corrupted if there is a config mismatch
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-11297
> URL: https://issues.redhat.com/browse/ISPN-11297
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core
> Affects Versions: 10.1.1.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 11.0.0.Alpha2, 10.1.3.Final
>
>
> With a persistent global state enabled, when a node that was previously part of a cluster rejoins it currently processes caches from the cluster state before the ones from the local state. This means that, if the cache configuration is incompatible, it will be overwritten with the one coming from the cluster.
> When joining the node should perform compatibility checks between caches in the cluster state and the local state before proceeding with creating them. If a mismatch is found, it should fail fast.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-3013) CLI not supports slashes in name as "defaultx/xx"
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-3013?page=com.atlassian.jira.plugin... ]
Tristan Tarrant closed ISPN-3013.
---------------------------------
Resolution: Out of Date
> CLI not supports slashes in name as "defaultx/xx"
> --------------------------------------------------
>
> Key: ISPN-3013
> URL: https://issues.redhat.com/browse/ISPN-3013
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Reporter: Vitalii Chepeliuk
> Priority: Minor
> Labels: cli
>
> When we connect from CLI to server. And configure our cache name to use / in names then name with slashes is correctly shown when we press <TAB> to autocomplete but If we choose this name of cache and press <ENTER> we get exception
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11280) ConcurrentModificationException in ConditionFuture
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11280?page=com.atlassian.jira.plugi... ]
Dan Berindei reopened ISPN-11280:
---------------------------------
> ConcurrentModificationException in ConditionFuture
> --------------------------------------------------
>
> Key: ISPN-11280
> URL: https://issues.redhat.com/browse/ISPN-11280
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Beta1
>
>
> {noformat}
> java.util.ConcurrentModificationException
> at java.base/java.util.IdentityHashMap$IdentityHashMapIterator.remove(IdentityHashMap.java:749)
> at java.base/java.util.IdentityHashMap$EntryIterator.remove(IdentityHashMap.java:850)
> at org.infinispan.util.concurrent.ConditionFuture.checkConditions(ConditionFuture.java:114)
> at org.infinispan.util.concurrent.ConditionFuture.lambda$updateAsync$1(ConditionFuture.java:98)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11347) Change default TOS for UDP
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11347?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11347:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7901
> Change default TOS for UDP
> --------------------------
>
> Key: ISPN-11347
> URL: https://issues.redhat.com/browse/ISPN-11347
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, 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: 11.0.0.Beta1
>
>
> The Linux kernel has some fairly sophisticated queueing disciplines like {{fq_codel}}, but the default one is {{pfifo_fast}}, and that's what our edg-perfXX machines use.
> {quote}
> pfifo_fast is like three tc-pfifo(8) queues side by side,
> where packets can be enqueued in any of the three bands based on
> their Type of Service bits or assigned priority.
> Not all three bands are dequeued simultaneously - as long as lower
> bands have traffic, higher bands are never dequeued. This can be used
> to prioritize interactive traffic or penalize 'lowest cost' traffic.
> ??[http://man7.org/linux/man-pages/man8/tc-pfifo_fast.8.html#ALGORITHM]??
> {quote}
> These are some examples of band mappings:
> {quote}
> {noformat}
> TOS Bits Means Linux Priority Band
> ------------------------------------------------------------
> 0x0 0 Normal Service 0 Best Effort 1
> 0x8 4 Maximize Throughput 2 Bulk 2
> 0x10 8 Minimize Delay 6 Interactive 0
> 0x18 12 mt+md 4 Int. Bulk 1
> {noformat}
> ??[http://man7.org/linux/man-pages/man8/tc-prio.8.html#QDISC_PARAMETERS]??
> {quote}
> By default {{UDP.tos="8"}}, which makes all UDP traffic go into band 2, lowest priority (bulk). HotRod clients and servers don't set a TOS on their sockets, so the client-server packets go into band 1, middle priority (best effort).
> {{FD_ALL}} and {{FD_ALL2}} heartbeats are also {{UDP}} traffic, and in some read-only client-server test there is enough client-server traffic in band 1 to delay the FD_ALL heartbeats for more than 10 seconds.
> We could either set the default TOS to {{0}} (best effort), or {{0x18}} (maximize throughput + minimize delay), the result is the same: band 1.
> We could also try to set the TOS to {{0x10}} to get them into band 0, but while it would work in Infinispan-only benchmarks, it would probably be unfair to other communications on the same machine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11347) Change default TOS for UDP
by Dan Berindei (Jira)
Dan Berindei created ISPN-11347:
-----------------------------------
Summary: Change default TOS for UDP
Key: ISPN-11347
URL: https://issues.redhat.com/browse/ISPN-11347
Project: Infinispan
Issue Type: Enhancement
Components: Configuration, Core
Affects Versions: 11.0.0.Alpha1, 10.1.2.Final, 9.4.18.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Beta1
The Linux kernel has some fairly sophisticated queueing disciplines like {{fq_codel}}, but the default one is {{pfifo_fast}}, and that's what our edg-perfXX machines use.
{quote}
pfifo_fast is like three tc-pfifo(8) queues side by side,
where packets can be enqueued in any of the three bands based on
their Type of Service bits or assigned priority.
Not all three bands are dequeued simultaneously - as long as lower
bands have traffic, higher bands are never dequeued. This can be used
to prioritize interactive traffic or penalize 'lowest cost' traffic.
??[http://man7.org/linux/man-pages/man8/tc-pfifo_fast.8.html#ALGORITHM]??
{quote}
These are some examples of band mappings:
{quote}
{noformat}
TOS Bits Means Linux Priority Band
------------------------------------------------------------
0x0 0 Normal Service 0 Best Effort 1
0x8 4 Maximize Throughput 2 Bulk 2
0x10 8 Minimize Delay 6 Interactive 0
0x18 12 mt+md 4 Int. Bulk 1
{noformat}
??[http://man7.org/linux/man-pages/man8/tc-prio.8.html#QDISC_PARAMETERS]??
{quote}
By default {{UDP.tos="8"}}, which makes all UDP traffic go into band 2, lowest priority (bulk). HotRod clients and servers don't set a TOS on their sockets, so the client-server packets go into band 1, middle priority (best effort).
{{FD_ALL}} and {{FD_ALL2}} heartbeats are also {{UDP}} traffic, and in some read-only client-server test there is enough client-server traffic in band 1 to delay the FD_ALL heartbeats for more than 10 seconds.
We could either set the default TOS to {{0}} (best effort), or {{0x18}} (maximize throughput + minimize delay), the result is the same: band 1.
We could also try to set the TOS to {{0x10}} to get them into band 0, but while it would work in Infinispan-only benchmarks, it would probably be unfair to other communications on the same machine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ISPN-11347) Change default TOS for UDP
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11347?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11347:
--------------------------------
Status: Open (was: New)
> Change default TOS for UDP
> --------------------------
>
> Key: ISPN-11347
> URL: https://issues.redhat.com/browse/ISPN-11347
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, 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: 11.0.0.Beta1
>
>
> The Linux kernel has some fairly sophisticated queueing disciplines like {{fq_codel}}, but the default one is {{pfifo_fast}}, and that's what our edg-perfXX machines use.
> {quote}
> pfifo_fast is like three tc-pfifo(8) queues side by side,
> where packets can be enqueued in any of the three bands based on
> their Type of Service bits or assigned priority.
> Not all three bands are dequeued simultaneously - as long as lower
> bands have traffic, higher bands are never dequeued. This can be used
> to prioritize interactive traffic or penalize 'lowest cost' traffic.
> ??[http://man7.org/linux/man-pages/man8/tc-pfifo_fast.8.html#ALGORITHM]??
> {quote}
> These are some examples of band mappings:
> {quote}
> {noformat}
> TOS Bits Means Linux Priority Band
> ------------------------------------------------------------
> 0x0 0 Normal Service 0 Best Effort 1
> 0x8 4 Maximize Throughput 2 Bulk 2
> 0x10 8 Minimize Delay 6 Interactive 0
> 0x18 12 mt+md 4 Int. Bulk 1
> {noformat}
> ??[http://man7.org/linux/man-pages/man8/tc-prio.8.html#QDISC_PARAMETERS]??
> {quote}
> By default {{UDP.tos="8"}}, which makes all UDP traffic go into band 2, lowest priority (bulk). HotRod clients and servers don't set a TOS on their sockets, so the client-server packets go into band 1, middle priority (best effort).
> {{FD_ALL}} and {{FD_ALL2}} heartbeats are also {{UDP}} traffic, and in some read-only client-server test there is enough client-server traffic in band 1 to delay the FD_ALL heartbeats for more than 10 seconds.
> We could either set the default TOS to {{0}} (best effort), or {{0x18}} (maximize throughput + minimize delay), the result is the same: band 1.
> We could also try to set the TOS to {{0x10}} to get them into band 0, but while it would work in Infinispan-only benchmarks, it would probably be unfair to other communications on the same machine.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month