[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3918:
------------------------------------
FORCE_WRITE_LOCK doesn't work in non-tx caches.
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Fix For: 8.0.0.Final
>
> Attachments: ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years