[Red Hat JIRA] (ISPN-12539) Server image doesn't accept numeric characters into password env
by Gustavo Lira e Silva (Jira)
Gustavo Lira e Silva created ISPN-12539:
-------------------------------------------
Summary: Server image doesn't accept numeric characters into password env
Key: ISPN-12539
URL: https://issues.redhat.com/browse/ISPN-12539
Project: Infinispan
Issue Type: Bug
Components: Docker
Affects Versions: 11.0.7.Final
Reporter: Gustavo Lira e Silva
if you run
{code:java}
docker run -p 11222:11222 -e USER="root" -e PASS="123456" infinispan/server{code}
You will receive
{noformat}
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
{noformat}
the env PASS is only accepting String
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months
[Red Hat JIRA] (ISPN-12538) Clustered Locks with zero-capacity throws ClassCastException
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12538?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on ISPN-12538:
-------------------------------------
I have not reproduced the {{ClassCastException}} with an embedded cluster. Instead I have discovered ISPN-12548: Replicated cache get ignores value in zero-capacity nodes
> Clustered Locks with zero-capacity throws ClassCastException
> ------------------------------------------------------------
>
> Key: ISPN-12538
> URL: https://issues.redhat.com/browse/ISPN-12538
> Project: Infinispan
> Issue Type: Bug
> Components: Clustered Locks
> Affects Versions: 12.0.0.Dev07
> Reporter: Ryan Emerson
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> When creating a cluster with no explicit clustered-locks configuration, i.e. num_Owners is not defined, a `ClassCastException` is thrown if a zero-capacity node joins the cluster and attempts to use a lock:
> {code:java}
> 10:10:36,564 ERROR (non-blocking-thread--p2-t2) [org.infinispan.topology.LocalTopologyManagerImpl] ISPN000230: Failed to start rebalance for cache org.infinispan.LOCKS java.util.concurrent.CompletionException: java.lang.ClassCastException: class org.infinispan.distribution.ch.impl.ReplicatedConsistentHash cannot be cast to class org.infinispan.distribution.ch.impl.DefaultConsistentHash (org.infinispan.distribution.ch.impl.ReplicatedConsistentHash and org.infinispan.distribution.ch.impl.DefaultConsistentHash are in unnamed module of loader java.net.URLClassLoader @6d03e736)
> at java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.accept(ActionSequencer.java:213)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.accept(ActionSequencer.java:179)
> at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
> at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:143)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.run(ActionSequencer.java:227)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:219)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.apply(ActionSequencer.java:179)
> at java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> 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)
> Caused by: java.lang.ClassCastException: class org.infinispan.distribution.ch.impl.ReplicatedConsistentHash cannot be cast to class org.infinispan.distribution.ch.impl.DefaultConsistentHash (org.infinispan.distribution.ch.impl.ReplicatedConsistentHash and org.infinispan.distribution.ch.impl.DefaultConsistentHash are in unnamed module of loader java.net.URLClassLoader @6d03e736)
> at org.infinispan.distribution.ch.impl.SyncConsistentHashFactory.union(SyncConsistentHashFactory.java:58)
> at org.infinispan.topology.LocalTopologyManagerImpl.doHandleRebalance(LocalTopologyManagerImpl.java:562)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleRebalance$16(LocalTopologyManagerImpl.java:531)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$orderOnCache$24(LocalTopologyManagerImpl.java:736)
> at org.infinispan.util.concurrent.ActionSequencer.safeNonBlockingCall(ActionSequencer.java:57)
> at org.infinispan.util.concurrent.ActionSequencer.access$400(ActionSequencer.java:32)
> at org.infinispan.util.concurrent.ActionSequencer$SequenceEntry.run(ActionSequencer.java:226)
> ... 8 more
> {code}
> Previously zero-capacity node was not supported with replicated-caches, however this is no longer the case so it should be possible for clustered-locks to work with a replicated cache without defining num_owners.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months
[Red Hat JIRA] (ISPN-12548) Replicated cache get ignores value in zero-capacity nodes
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12548?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12548:
--------------------------------
Status: Open (was: New)
> Replicated cache get ignores value in zero-capacity nodes
> ---------------------------------------------------------
>
> Key: ISPN-12548
> URL: https://issues.redhat.com/browse/ISPN-12548
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 12.0.0.Dev07
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.CR1
>
>
> In replicated caches that meet several other conditions, {{cache.get(key)}} is optimized to skip the interceptor chain and to read the entry directly from the data container.
> This optimization assumes that the local cache has all the values, and the assumption fails when the local node has a zero capacity factor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months
[Red Hat JIRA] (ISPN-12351) ImmutableListCopy makes too many copies
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12351?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12351:
-----------------------------------
Fix Version/s: 12.0.0.CR1
(was: 12.0.0.Dev07)
> ImmutableListCopy makes too many copies
> ---------------------------------------
>
> Key: ISPN-12351
> URL: https://issues.redhat.com/browse/ISPN-12351
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 12.0.0.Dev03
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 12.0.0.CR1
>
>
> An array copy is not needed when creating a new {{ImmutableListCopy}} instance from another {{ImmutableListCopy}}.
> The constructor with 2 list parameters can also avoid one array allocation by pre-allocating the array, or by using one list's array when the other list is empty.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 5 months