June 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5558: ------------------------------- Status: Open (was: New) > DistributedTaskPart.equals() implementation is wrong > ---------------------------------------------------- > > Key: ISPN-5558 > URL: https://issues.jboss.org/browse/ISPN-5558 > Project: Infinispan > Issue Type: Bug > Components: Core, Distributed Execution and Map/Reduce > Affects Versions: 7.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta1, 8.0.0.Final > > > {{DistributedExecutorService.submitEverywhere()}} returns a list of futures, one future for each targeted node. Because of how {{DistributedTaskPart.equals()}} is implemented, all the futures in the list appear to be equal, even though their target node is different and their result will also be different. > The simplest fix would be to remove the equals() and hashCode() overloads from {{DistributedTaskPart}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5558: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1232733 > DistributedTaskPart.equals() implementation is wrong > ---------------------------------------------------- > > Key: ISPN-5558 > URL: https://issues.jboss.org/browse/ISPN-5558 > Project: Infinispan > Issue Type: Bug > Components: Core, Distributed Execution and Map/Reduce > Affects Versions: 7.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta1, 8.0.0.Final > > > {{DistributedExecutorService.submitEverywhere()}} returns a list of futures, one future for each targeted node. Because of how {{DistributedTaskPart.equals()}} is implemented, all the futures in the list appear to be equal, even though their target node is different and their result will also be different. > The simplest fix would be to remove the equals() and hashCode() overloads from {{DistributedTaskPart}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5558: ---------------------------------- Summary: DistributedTaskPart.equals() implementation is wrong Key: ISPN-5558 URL: https://issues.jboss.org/browse/ISPN-5558 Project: Infinispan Issue Type: Bug Components: Core, Distributed Execution and Map/Reduce Affects Versions: 7.2.2.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta1, 8.0.0.Final {{DistributedExecutorService.submitEverywhere()}} returns a list of futures, one future for each targeted node. Because of how {{DistributedTaskPart.equals()}} is implemented, all the futures in the list appear to be equal, even though their target node is different and their result will also be different. The simplest fix would be to remove the equals() and hashCode() overloads from {{DistributedTaskPart}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5557) Core threading redesign

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5557?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5557: ------------------------------- Summary: Core threading redesign (was: Thread usage redesign in core) > Core threading redesign > ----------------------- > > Key: ISPN-5557 > URL: https://issues.jboss.org/browse/ISPN-5557 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.0.0.Final > > > Infinispan needs a lot of threads, because everything is synchronous: locking, remote command invocations, cache writers. This causes various issues, from general context switching overhead to the thread pools getting full and causing deadlocks. > We should redesign the core so that most blocking happens on the application threads, and the number of internal threads is kept to a minimum. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5557) Thread usage redesign in core

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5557: ---------------------------------- Summary: Thread usage redesign in core Key: ISPN-5557 URL: https://issues.jboss.org/browse/ISPN-5557 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 7.2.2.Final Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 8.0.0.Final Infinispan needs a lot of threads, because everything is synchronous: locking, remote command invocations, cache writers. This causes various issues, from general context switching overhead to the thread pools getting full and causing deadlocks. We should redesign the core so that most blocking happens on the application threads, and the number of internal threads is kept to a minimum. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4720: ---------------------------------- Assignee: Galder Zamarreño (was: Dan Berindei) > Values data reverts in Compatibilty mode in Infinispan 6.0.2 > ------------------------------------------------------------ > > Key: ISPN-4720 > URL: https://issues.jboss.org/browse/ISPN-4720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.2.0.Final > Environment: Linux 3.15.8-200.fc20.x86_64 > Reporter: Prashant Thakur > Assignee: Galder Zamarreño > Priority: Critical > Labels: Infinispan > Fix For: 7.0.0.Alpha3 > > Attachments: BaseDistributionInterceptor.java, distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out, TxDistributionInterceptor.java > > > 1) The owners of the keys are Node1 and Node4 > 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390] > 2. The request for update came to Node2 a non-owner. > 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED} > 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data. > 4. While doing a get from Node 1 we again receive the old value -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4720: ------------------------------------ [~galder.zamarreno] "type conversion issues" sounds a lot like ISPN-5477, could you have a look at Prashanth's proposed changes in case there's something else that needs to be done? > Values data reverts in Compatibilty mode in Infinispan 6.0.2 > ------------------------------------------------------------ > > Key: ISPN-4720 > URL: https://issues.jboss.org/browse/ISPN-4720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.2.0.Final > Environment: Linux 3.15.8-200.fc20.x86_64 > Reporter: Prashant Thakur > Assignee: Dan Berindei > Priority: Critical > Labels: Infinispan > Fix For: 7.0.0.Alpha3 > > Attachments: BaseDistributionInterceptor.java, distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out, TxDistributionInterceptor.java > > > 1) The owners of the keys are Node1 and Node4 > 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390] > 2. The request for update came to Node2 a non-owner. > 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED} > 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data. > 4. While doing a get from Node 1 we again receive the old value -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5042) Remote gets caused by writes could be replicated only to the primary owner

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5042?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5042: ---------------------------------- Assignee: (was: Dan Berindei) > Remote gets caused by writes could be replicated only to the primary owner > -------------------------------------------------------------------------- > > Key: ISPN-5042 > URL: https://issues.jboss.org/browse/ISPN-5042 > Project: Infinispan > Issue Type: Enhancement > Components: Core, State Transfer > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Priority: Minor > Labels: 7.0 > Fix For: 8.0.0.Final > > > For write operations that need the previous value, a write CH-only owner that doesn't have a key locally will attempt to retrieve the key from the read CH-owners. > Sending the remote get command to all the previous owners will create extra load on the cluster during state transfer, so it should be more efficient to send the remote get only to the primary owner. Even though the latency of some write operations will be higher, the average latency should be better. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4564) Optimize test suite GC settings in CI

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4564?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-4564. -------------------------------- Fix Version/s: 8.0.0.Alpha2 Resolution: Done `-XX:+UseG1GC` has been in use for a while and seems to be working fine. However, verbose GC logs may be breaking the master-fork communication in the surefire plugin (ISPN-5472, SUREFIRE-1157), so I'm disabling them. > Optimize test suite GC settings in CI > ------------------------------------- > > Key: ISPN-4564 > URL: https://issues.jboss.org/browse/ISPN-4564 > Project: Infinispan > Issue Type: Task > Components: Build process > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.0.0.Alpha2 > > > Some CI test logs show big pauses (> 5s) causing intermittent failure. We should monitor the GC activity during the builds and maybe enable UseConcMarkSweepGC or UseG1GC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4564) Optimize test suite GC settings in CI

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4564?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-4564 at 6/17/15 6:48 AM: ------------------------------------------------------------- `-XX:+UseG1GC` has been in use for a while and seems to be working fine. However, verbose GC logs may be breaking the master-fork communication in the surefire plugin (ISPN-5472, [SUREFIRE-1157|https://issues.apache.org/jira/browse/SUREFIRE-1157]), so I'm disabling them. was (Author: dan.berindei): `-XX:+UseG1GC` has been in use for a while and seems to be working fine. However, verbose GC logs may be breaking the master-fork communication in the surefire plugin (ISPN-5472, SUREFIRE-1157), so I'm disabling them. > Optimize test suite GC settings in CI > ------------------------------------- > > Key: ISPN-4564 > URL: https://issues.jboss.org/browse/ISPN-4564 > Project: Infinispan > Issue Type: Task > Components: Build process > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.0.0.Alpha2 > > > Some CI test logs show big pauses (> 5s) causing intermittent failure. We should monitor the GC activity during the builds and maybe enable UseConcMarkSweepGC or UseG1GC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 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 2015