June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2353) Allow KOut/VOut emitting Mapper where VOut is null

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2353?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2353: ---------------------------------------- I've tried to replicate the issue in this test [1], but no luck so far. I've replied to Matej to see if the issue is still present. [1] https://github.com/galderz/infinispan/commit/77beb0925f0afc154f10b6137ab2... > Allow KOut/VOut emitting Mapper where VOut is null > -------------------------------------------------- > > Key: ISPN-2353 > URL: https://issues.jboss.org/browse/ISPN-2353 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > In some cases Mapper being executed on remote nodes might produce intermediate KOut/VOut pairs where VOut is null. Should allow/account for that possibility? Currently such tasks fail with NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2353) Allow KOut/VOut emitting Mapper where VOut is null

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2353?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2353: ----------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Allow KOut/VOut emitting Mapper where VOut is null > -------------------------------------------------- > > Key: ISPN-2353 > URL: https://issues.jboss.org/browse/ISPN-2353 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > In some cases Mapper being executed on remote nodes might produce intermediate KOut/VOut pairs where VOut is null. Should allow/account for that possibility? Currently such tasks fail with NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2956: ----------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.Final) > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: hotrod-java-client, remote-clients > Fix For: 6.1.0.Final > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2835: ----------------------------------- Assignee: Adrian Nistor (was: Galder Zamarreño) > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Adrian Nistor > Labels: onboard > Fix For: 5.3.0.Final > > Attachments: infinispan.log, mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2835: ---------------------------------------- Scaled down test to replicate issue: https://github.com/galderz/infinispan/commit/dee83cdf4cecdd2f53553f08085c... > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Labels: onboard > Fix For: 5.3.0.Final > > Attachments: infinispan.log, mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2835: ----------------------------------- Attachment: infinispan.log > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Labels: onboard > Fix For: 5.3.0.Final > > Attachments: infinispan.log, mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3245) ReplSyncDistributedExecutorTest.testTaskCancellation fails intermittently

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3245: ---------------------------------- Summary: ReplSyncDistributedExecutorTest.testTaskCancellation fails intermittently Key: ISPN-3245 URL: https://issues.jboss.org/browse/ISPN-3245 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.3.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.3.0.Final The test cancels a task and checks that the remote thread has been interrupted. But the check can happen before the task execution thread actually wakes up, in which case the test fails: {noformat} 21:09:36,236 ERROR (testng-ReplSyncDistributedExecutorTest:) [UnitTestTestNGListener] Test testTaskCancellation(org.infinispan.distexec.ReplSyncDistributedExecutorTest) failed. java.lang.AssertionError at org.infinispan.distexec.ReplSyncDistributedExecutorTest.testTaskCancellation(ReplSyncDistributedExecutorTest.java:89) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2835: ----------------------------------- Fix Version/s: 5.3.0.Final (was: 6.0.0.Final) > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Labels: onboard > Fix For: 5.3.0.Final > > Attachments: mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2835: ---------------------------------------- @Anna, you might have a point, but we had a similar issue in this area about starting caches on the fly for map/reduce tasks, so I'm gonna have a look at this. @Ray, FYI, your test still fails with master. > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Labels: onboard > Fix For: 6.0.0.Final > > Attachments: mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Work on ISPN-2835 started by Galder Zamarreño. > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Galder Zamarreño > Labels: onboard > Fix For: 6.0.0.Final > > Attachments: mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013