June 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9288) Use transform() to decorate the cache used by Hot Rod Transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-9288?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9288: ------------------------------ Description: Use the {{transform()}} method instead of checking manually the instance of the class to decorate. Notes: the server wraps the cache to use! was: Use the {{transform()}} method instead of checking the instance of the class to decorate. > Use transform() to decorate the cache used by Hot Rod Transactions > ------------------------------------------------------------------ > > Key: ISPN-9288 > URL: https://issues.jboss.org/browse/ISPN-9288 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Final > > > Use the {{transform()}} method instead of checking manually the instance of the class to decorate. Notes: the server wraps the cache to use! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9288) Use transform() to decorate the cache used by Hot Rod Transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-9288?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-9288: ------------------------------ Description: Use the {{transform()}} method instead of checking the instance of the class to decorate. > Use transform() to decorate the cache used by Hot Rod Transactions > ------------------------------------------------------------------ > > Key: ISPN-9288 > URL: https://issues.jboss.org/browse/ISPN-9288 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Final > > > Use the {{transform()}} method instead of checking the instance of the class to decorate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9288) Use transform() to decorate the cache used by Hot Rod Transactions

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-9288: --------------------------------- Summary: Use transform() to decorate the cache used by Hot Rod Transactions Key: ISPN-9288 URL: https://issues.jboss.org/browse/ISPN-9288 Project: Infinispan Issue Type: Bug Components: Hot Rod, Transactions Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 9.3.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9281) Netty Epoll checker should handle ClassNotFoundException

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-9281?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9281: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Netty Epoll checker should handle ClassNotFoundException > -------------------------------------------------------- > > Key: ISPN-9281 > URL: https://issues.jboss.org/browse/ISPN-9281 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Affects Versions: 9.3.0.CR1, 9.2.4.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.3.0.Final, 9.2.5.Final > > > The poll checking code should catch ClassNotFoundException when netty-transport-native-epoll is not on the classpath -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9187) Lost segments logged when node leaves during rebalance

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9187?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9187: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6055 > Lost segments logged when node leaves during rebalance > ------------------------------------------------------ > > Key: ISPN-9187 > URL: https://issues.jboss.org/browse/ISPN-9187 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.3.Final, 9.3.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Final > > > When a node leaves during rebalance, we remove the leaver from the current CH and from the pending CH with {{ConsistentHashFactory.updateMembers()}}. However, since the 4-phase rebalance changes joiners are also removed from the pending CH. > In the following log numOwners=2 and pending CH had one segment (239) owned by a joiner (D) and a leaver (B). The updated pending CH doesn't have either B or D, this means both owners are lost and random owners (C and A) are elected. A sees that it was allocated new segments from {{updateMembers}} and logs that the segment has been lost: > {noformat} > 08:53:01,528 INFO (remote-thread-test-NodeA-p2-t6:[cluster-listener]) [CLUSTER] [Context=cluster-listener] ISPN100002: Starting rebalance with members [test-NodeA-15001, test-NodeB-55628, test-NodeC-62395, test-NodeD-29215], phase READ_OLD_WRITE_ALL, topology id 10 > 08:53:01,554 TRACE (transport-thread-test-NodeD-p28-t2:[Topology-cluster-listener]) [CacheTopology] Current consistent hash's routing table: test-NodeA-15001 primary: {... 237-238 244-245 248-250 252 254}, backup: {... 235-236 243 246-247 251 253} > test-NodeB-55628 primary: {... 231 234 240 242}, backup: {... 232-233 239 241 255} > test-NodeC-62395 primary: {... 232-233 235-236 239 241 243 246-247 251 253 255}, backup: {... 231 234 237-238 240 242 244-245 248-250 252 254} > 08:53:01,554 TRACE (transport-thread-test-NodeD-p28-t2:[Topology-cluster-listener]) [CacheTopology] Pending consistent hash's routing table: test-NodeA-15001 primary: {... 237-238 245 248 252}, backup: {... 235-236 244 246-247 251} > test-NodeB-55628 primary: {... 231 240 242}, backup: {... 230 239 241} > test-NodeC-62395 primary: {... 232-233 235-236 241 243 246-247 251 253 255}, backup: {... 231 234 240 242 245 249-250 252 254} > test-NodeD-29215 primary: {... 234 239 244 249-250 254}, backup: {... 232-233 237-238 243 248 253 255} > 08:53:01,606 TRACE (remote-thread-test-NodeA-p2-t5:[cluster-listener]) [ClusterCacheStatus] Removed node test-NodeB-55628 from cache cluster-listener: members = [test-NodeA-15001, test-NodeC-62395, test-NodeD-29215], joiners = [test-NodeD-29215] > 08:53:01,611 TRACE (remote-thread-test-NodeA-p2-t5:[cluster-listener]) [CacheTopology] Current consistent hash's routing table: test-NodeA-15001 primary: {... 237-238 244-245 248-250 252 254}, backup: {... 235-236 243 246-247 251 253} > test-NodeC-62395 primary: {... 230-236 239-243 246-247 251 253 255}, backup: {... 237-238 244-245 248-250 252 254} > 08:53:01,611 TRACE (remote-thread-test-NodeA-p2-t5:[cluster-listener]) [CacheTopology] Pending consistent hash's routing table: test-NodeA-15001 primary: {... 237-238 244-245 248 252}, backup: {... 235-236 239 246-247 251} > test-NodeC-62395 primary: {... 227-236 239-243 246-247 249-251 253-255}, backup: {... 226 245 252} > 08:53:01,613 TRACE (transport-thread-test-NodeA-p4-t1:[Topology-cluster-listener]) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=11, phase=READ_OLD_WRITE_ALL, rebalanceId=4, currentCH=DefaultConsistentHash{ns=256, owners = (2)[test-NodeA-15001: 134+45, test-NodeC-62395: 122+50]}, pendingCH=DefaultConsistentHash{ns=256, owners = (2)[test-NodeA-15001: 129+45, test-NodeC-62395: 127+28]}, unionCH=DefaultConsistentHash{ns=256, owners = (2)[test-NodeA-15001: 134+62, test-NodeC-62395: 122+68]}, actualMembers=[test-NodeA-15001, test-NodeC-62395, test-NodeD-29215], persistentUUIDs=[0506cc27-9762-4703-ad56-6a3bf7953529, c365b93f-e46c-4f11-ab46-6cafa2b2d92b, d3f21b0d-07f2-4089-b160-f754e719de83]} on cache cluster-listener > 08:53:01,662 TRACE (transport-thread-test-NodeA-p4-t1:[Topology-cluster-listener]) [StateConsumerImpl] On cache cluster-listener we have: new segments: {1-18 21 30-53 56-63 67 69-73 75-78 81-85 88-101 107-115 117-118 125-134 136-139 142-156 158-165 168-170 172-174 177-179 181-188 193-211 214-226 228-229 235-239 243-254}; old segments: {1-15 30-53 56-63 69-73 75-77 81-85 88-101 107-115 117-118 125-131 136-139 142-145 150-156 158-165 168-170 172-174 177-179 183-188 193-211 214-218 220-226 228-229 235-238 243-254} > 08:53:01,663 TRACE (transport-thread-test-NodeA-p4-t1:[Topology-cluster-listener]) [StateConsumerImpl] On cache cluster-listener we have: added segments: {16-18 21 67 78 132-134 146-149 181-182 219 239}; removed segments: {} > 08:53:01,663 DEBUG (transport-thread-test-NodeA-p4-t1:[Topology-cluster-listener]) [StateConsumerImpl] Not requesting segments {16-18 21 67 78 132-134 146-149 181-182 219 239} because the last owner left the cluster > {noformat} > There isn't any visible inconsistency: A only owns segment 239 for writing, and the coordinator immediately starts a new rebalance, ignoring the pending CH that it sent out earlier. However, the new rebalance causes its own problems: ISPN-8240. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9287) Integration test suite fails when JAVA_HOME is not set

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9287: ---------------------------------- Summary: Integration test suite fails when JAVA_HOME is not set Key: ISPN-9287 URL: https://issues.jboss.org/browse/ISPN-9287 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 9.3.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.3.0.Final The build tries to run the {{kill-server}} Ant target before and after running the integration test suite. The target assumes that the server is running, and if none of ps/jps/lsof/netstat find the server it fails the build: {noformat} Caused by: org.apache.tools.ant.BuildException: The following error occurred while executing this line: /home/jenkins/workspace/polarion-report/5fee2853/server/integration/src/main/ant/infinispan-server.xml:102: Not yet supported on UNIX/WINDOWS favour without working ps/lsof/jps/netstat {noformat} Normally this doesn't happen because the {{jps}} check is not as strict as the others, passing if {{jps}} finds any java process (and not necessarily a server). But if {{JAVA_HOME}} is not defined, the {{jps}} check also fails: {noformat} [exec] Execute failed: java.io.IOException: Cannot run program "${env.JAVA_HOME}/bin/jps" (in directory "/home/jenkins/workspace/polarion-report/5fee2853/integrationtests/wildfly-modules"): error=2, No such file or directory {noformat} We should change the {{kill-server}} target so that it doesn't assume the server is already running. Maybe it could also use ps/jps to find the pid of the server, and lsof/netstat to check that the server really is really stopped after it was killed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9287) Integration test suite fails when JAVA_HOME is not set

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9287?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9287: ------------------------------- Status: Open (was: New) > Integration test suite fails when JAVA_HOME is not set > ------------------------------------------------------ > > Key: ISPN-9287 > URL: https://issues.jboss.org/browse/ISPN-9287 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.3.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Final > > > The build tries to run the {{kill-server}} Ant target before and after running the integration test suite. The target assumes that the server is running, and if none of ps/jps/lsof/netstat find the server it fails the build: > {noformat} > Caused by: org.apache.tools.ant.BuildException: The following error occurred while executing this line: > /home/jenkins/workspace/polarion-report/5fee2853/server/integration/src/main/ant/infinispan-server.xml:102: Not yet supported on UNIX/WINDOWS favour without working ps/lsof/jps/netstat > {noformat} > Normally this doesn't happen because the {{jps}} check is not as strict as the others, passing if {{jps}} finds any java process (and not necessarily a server). But if {{JAVA_HOME}} is not defined, the {{jps}} check also fails: > {noformat} > [exec] Execute failed: java.io.IOException: Cannot run program "${env.JAVA_HOME}/bin/jps" (in directory "/home/jenkins/workspace/polarion-report/5fee2853/integrationtests/wildfly-modules"): error=2, No such file or directory > {noformat} > We should change the {{kill-server}} target so that it doesn't assume the server is already running. Maybe it could also use ps/jps to find the pid of the server, and lsof/netstat to check that the server really is really stopped after it was killed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9286) WriteBehindFaultToleranceTest Failures

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-9286: ---------------------------------- Summary: WriteBehindFaultToleranceTest Failures Key: ISPN-9286 URL: https://issues.jboss.org/browse/ISPN-9286 Project: Infinispan Issue Type: Bug Components: Core, Loaders and Stores Affects Versions: 9.3.0.CR1 Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 9.3.0.Final #testBlockingOnStoreAvailabilityChange failure due to the async write not completing before store.size is called. {code:java} java.lang.AssertionError: expected:<1> but was:<0> at org.infinispan.persistence.WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange(WriteBehindFaultToleranceTest.java:55) at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ... Removed 23 stack frames {code} #testWritesFailSilentlyWhenConfigured failure due to the async write not being executed on the store before the entry is loaded from the store. {code:java} java.lang.NullPointerException at org.infinispan.persistence.WriteBehindFaultToleranceTest.testWritesFailSilentlyWhenConfigured(WriteBehindFaultToleranceTest.java:110) at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ... Removed 18 stack frames {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9264) StringBasedStoreInvalidationCacheSyncIT Failures

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9264?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9264: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6054 (was: https://github.com/infinispan/infinispan/pull/6052) > StringBasedStoreInvalidationCacheSyncIT Failures > ------------------------------------------------ > > Key: ISPN-9264 > URL: https://issues.jboss.org/browse/ISPN-9264 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.3.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > > {code:java} > testRemoveNonExistentEntry > java.lang.AssertionError: Read timeout at org.infinispan.server.test.cs.jdbc.multinode.StringBasedStoreInvalidationCacheSyncIT.testRemoveNonExistentEntry(StringBasedStoreInvalidationCacheSyncIT.java:82) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9285) Investigate LHD (least hit density) eviction algorithm

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9285: ---------------------------------- Summary: Investigate LHD (least hit density) eviction algorithm Key: ISPN-9285 URL: https://issues.jboss.org/browse/ISPN-9285 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 9.3.0.CR1 Reporter: Dan Berindei Assignee: William Burns {quote} Least hit density (LHD) is an eviction policy based on hit density. LHD monitors objects online and uses conditional probability to predict their likely behavior. LHD draws on many different object features (e.g., age, frequency, application id, and size), and easily supports others. Dynamic ranking enables LHD to adapt its eviction strategy to different application workloads over time without any hand tuning. For example, on a certain workload, LHD may initially approximate LRU, then switch to most recently used (MRU), least frequently used (LFU), or a combination thereof. {quote} http://www.cs.cmu.edu/~beckmann/publications/papers/2018.nsdi.lhd.pdf -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2018