[JBoss JIRA] (ISPN-8732) ClusteredLockSplitBrainTest hangs
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8732?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8732:
-----------------------------------------
Please do it, thanks
> ClusteredLockSplitBrainTest hangs
> ---------------------------------
>
> Key: ISPN-8732
> URL: https://issues.jboss.org/browse/ISPN-8732
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.CR1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> {noformat}
> "testng-ClusteredLockSplitBrainTest[DIST_SYNC]" #13 prio=5 os_prio=0 tid=0x00007f24d46c4ca0 nid=0x1f9d waiting on condition [0x00007f24a87f0000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ff4209f8> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:42)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.assertFailureFromMinorityPartition(ClusteredLockSplitBrainTest.java:170)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition(ClusteredLockSplitBrainTest.java:165)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-8732) ClusteredLockSplitBrainTest hangs
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8732?page=com.atlassian.jira.plugin.... ]
Katia Aresti commented on ISPN-8732:
------------------------------------
should be backported too, do you wish to do it, or I do it myself when merged ?
> ClusteredLockSplitBrainTest hangs
> ---------------------------------
>
> Key: ISPN-8732
> URL: https://issues.jboss.org/browse/ISPN-8732
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.CR1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> {noformat}
> "testng-ClusteredLockSplitBrainTest[DIST_SYNC]" #13 prio=5 os_prio=0 tid=0x00007f24d46c4ca0 nid=0x1f9d waiting on condition [0x00007f24a87f0000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ff4209f8> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:42)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.assertFailureFromMinorityPartition(ClusteredLockSplitBrainTest.java:170)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.testAutoReleaseIfLockIsAcquiredFromAMinorityPartition(ClusteredLockSplitBrainTest.java:165)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-8693) Improve ControlledRpcManager
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8693?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8693:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.CR2
Resolution: Done
> Improve ControlledRpcManager
> ----------------------------
>
> Key: ISPN-8693
> URL: https://issues.jboss.org/browse/ISPN-8693
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Final, 9.2.0.CR2
>
>
> The {{ControlledRpcManager}} behaviour is not always obvious: because it only blocks once, it has a lot of tacked-on features to better filter what command to block on.
> Block all commands would be better, because the test would have to unblock them explicitly and make it clear what commands it expects.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-8704) Hot Rod access log is broken
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8704?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8704:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.CR2
Resolution: Done
> Hot Rod access log is broken
> ----------------------------
>
> Key: ISPN-8704
> URL: https://issues.jboss.org/browse/ISPN-8704
> Project: Infinispan
> Issue Type: Bug
> Components: REST, Server
> Affects Versions: 9.2.0.Beta2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.CR2
>
>
> The Hot Rod access log is broken in several ways:
> Todo:
> - remove the thread name
> - only print the remote address, without the initial / and the port
> - fix the processing time, and print it only once
> - print the request time using an appropriate format: [10/Oct/2000:13:55:36 -0700]
> - use a nicer logger category instead of the class name of the logger
> - print the user principal
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-8729) Use async operations in Hot Rod server
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8729?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8729:
------------------------------
Status: Open (was: New)
> Use async operations in Hot Rod server
> --------------------------------------
>
> Key: ISPN-8729
> URL: https://issues.jboss.org/browse/ISPN-8729
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.CR1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> The server should avoid context switches by starting commands directly from event loop instead of handing them off to another executor. This requires ISPN-8336 to make the async chain completely non-blocking.
> Along with the overhaul we should structure cache/counter/multimap operations nicely.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-8700) REST access log is broken
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8700?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8700:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.CR2
Resolution: Done
> REST access log is broken
> -------------------------
>
> Key: ISPN-8700
> URL: https://issues.jboss.org/browse/ISPN-8700
> Project: Infinispan
> Issue Type: Bug
> Components: REST, Server
> Affects Versions: 9.2.0.Beta2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.CR2
>
>
> The REST access log is broken in several ways:
> (REST-REST-ServerWorker-6-1) /127.0.0.1:42054 [54208501] "GET /" 404 0 13 54208501 ms
> (REST-REST-ServerWorker-6-1) /127.0.0.1:42054 [54261112] "GET /rest/default" 200 0 51 54261112 ms
> Todo:
> - remove the thread name
> - only print the remote address, without the initial / and the port
> - fix the processing time, and print it only once
> - print the request time using an appropriate format: [10/Oct/2000:13:55:36 -0700]
> - use a nicer logger category instead of the class name of the logger
> - print the user principal
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months
[JBoss JIRA] (ISPN-2491) Order of locks in optimistic locking is not strict
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-2491?page=com.atlassian.jira.plugin.... ]
Radim Vansa closed ISPN-2491.
-----------------------------
Resolution: Out of Date
Locking is not ordered by hashcodes anymore. The locks on each primary are requested in a synchronized block, introducing order on the requests. The locks are fair, and therefore two transactions sharing a set of keys will have the subset served in the same order.
> Order of locks in optimistic locking is not strict
> --------------------------------------------------
>
> Key: ISPN-2491
> URL: https://issues.jboss.org/browse/ISPN-2491
> Project: Infinispan
> Issue Type: Quality Risk
> Components: Transactions
> Affects Versions: 5.1.8.Final, 5.2.0.Beta3
> Reporter: Radim Vansa
> Priority: Minor
>
> In OptimisticLockingInterceptor, the keys are ordered according to their hash. However, the hashes can still collide, which may result in a deadlock if two keys with identical hash (only 32-bit) are sorted to different order. We should try to check if the keys are Comparable or let user provide some comparator class in config, and use the compare of hash only as the last resort.
> In all cases, a warning should be emitted if the compare operation had non-strict result.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 11 months