December 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2616) Write skew check fails in clustered mode (both DIST and REPL) if the key being checked was not transfered yet to local node by state transfer

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2616?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2616: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1503 > Write skew check fails in clustered mode (both DIST and REPL) if the key being checked was not transfered yet to local node by state transfer > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2616 > URL: https://issues.jboss.org/browse/ISPN-2616 > Project: Infinispan > Issue Type: Feature Request > Components: State transfer, Transactions > Affects Versions: 5.2.0.ALPHA1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.2.0.Beta6 > > > The write to keys that are not yet in the local DataContainer results in a failed write skew check. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2366) Allow getCache() to return before the node receives any state

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2366?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2366: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1503 > Allow getCache() to return before the node receives any state > ------------------------------------------------------------- > > Key: ISPN-2366 > URL: https://issues.jboss.org/browse/ISPN-2366 > Project: Infinispan > Issue Type: Task > Components: State transfer > Affects Versions: 5.2.0.Alpha4 > Reporter: Dan Berindei > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > > With NBST it's possible to use a cache without having any local state. We should allow getCache() to return as soon as the joiner has received a consistent hash (actually CacheTopology) from the coordinator. > This is related to ISPN-1394 - joiners should be able to work even if rebalancing is blocked. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2643) Configure the Java Hot Rod client to always go to the main data owner when requesting data

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2643?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2643: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1529 > Configure the Java Hot Rod client to always go to the main data owner when requesting data > ------------------------------------------------------------------------------------------ > > Key: ISPN-2643 > URL: https://issues.jboss.org/browse/ISPN-2643 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.Beta5 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.2.0.CR1, 5.2.0.Final > > > ATM the HR client picks randomly a node owner when it writes data. > With ISPN-2552 in place, this is suboptimal, as during writes the secondary owner delegates the write to the main owner for lock acquisition, which means an additional RPC. We should make the HR client always write to the main data owner directly. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2641) Use RpcManager#getMembers instead of Transport#getMembers if necessary

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2641?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2641: ------------------------------------- I've just spotted 3 wrong usages in ReplicationInterceptor in methods visitPrepareCommand, visitLockControlCommand and retrieveFromRemoteSource. > Use RpcManager#getMembers instead of Transport#getMembers if necessary > ---------------------------------------------------------------------- > > Key: ISPN-2641 > URL: https://issues.jboss.org/browse/ISPN-2641 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.0.Beta5 > Reporter: Vladimir Blagojevic > Assignee: Mircea Markus > Fix For: 5.2.0.Final > > > Recently we have added RpcManager#getMembers method which returns cache members rather that entire cluster members returned by Transport#getMembers. We should review the entire codebase very carefully and replace instances of Transport#getMembers with RpcManager#getMembers if necessary. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2209) HotRod client occasionally reports invalid magic number in elasticity tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2209?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2209: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 807741|https://bugzilla.redhat.com/show_bug.cgi?id=807741] I've run 2 tests with JDG 6.1.0.ER5 that previously demonstrated this issue and haven't seen it. ER5 build is burdened with other errors that might affect manifestation of this issue, namely bugzillas 886565, 886549, 887323 This heisenbug wasn't easy to spot even in builds where it was confirmed, however for this build, I think these two tests are enough, if the issue reappears, I'll reopen. The tests I did were elasticity tests 8-16-8 and 16-32-16 in hyperion: http://www.qa.jboss.com/~mlinhard/hyperion3/run0009 http://www.qa.jboss.com/~mlinhard/hyperion3/run0010 > HotRod client occasionally reports invalid magic number in elasticity tests > --------------------------------------------------------------------------- > > Key: ISPN-2209 > URL: https://issues.jboss.org/browse/ISPN-2209 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.1.5.FINAL > Environment: Hyperion w/32 nodes > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > > During a 32-node elasticity tests, HotRod clients report "invalid magic number" -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2209) HotRod client occasionally reports invalid magic number in elasticity tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2209?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2209: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 807741|https://bugzilla.redhat.com/show_bug.cgi?id=807741] from ON_QA to VERIFIED > HotRod client occasionally reports invalid magic number in elasticity tests > --------------------------------------------------------------------------- > > Key: ISPN-2209 > URL: https://issues.jboss.org/browse/ISPN-2209 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.1.5.FINAL > Environment: Hyperion w/32 nodes > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > > During a 32-node elasticity tests, HotRod clients report "invalid magic number" -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2646) SimpleClusteredVersion should use the topology id instead of the JGroups view id

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2646?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2646: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1503 > SimpleClusteredVersion should use the topology id instead of the JGroups view id > -------------------------------------------------------------------------------- > > Key: ISPN-2646 > URL: https://issues.jboss.org/browse/ISPN-2646 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.ALPHA1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.2.0.Beta6 > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2054) Incorrect notification semantics with event.isPre=false

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2054?page=com.atlassian.jira.plugin.... ] Work on ISPN-2054 started by Galder Zamarreño. > Incorrect notification semantics with event.isPre=false > ------------------------------------------------------- > > Key: ISPN-2054 > URL: https://issues.jboss.org/browse/ISPN-2054 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 5.1.4.FINAL, 5.1.5.CR1 > Reporter: Julio Faerman > Assignee: Galder Zamarreño > Priority: Minor > Labels: cache, infinispan, listener, size > Fix For: 5.2.0.CR1, 5.2.0.Final > > > I have found that on CacheEntryCreated the cache size is the same both when pre=true and pre=false, what can be wrong. The discussion can be read in the forum reference. > Here is the reproducible test case: > https://github.com/jfaerman/sandbox/blob/master/ispn-tests/src/test/java/... > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1407) Make sure the server_list attribute of the Hot Rod Client can be updated dynamically

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1407?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-1407: --------------------------------------- Why do we need HR protocol changes ? Can't we just fill the topology cache on cluster A with the addresses from cluster B and make sure all clients perform a GET to retrieve the new topology view ? > Make sure the server_list attribute of the Hot Rod Client can be updated dynamically > ------------------------------------------------------------------------------------ > > Key: ISPN-1407 > URL: https://issues.jboss.org/browse/ISPN-1407 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > > when starting a rolling upgrade it will be needed to upgrade the server_lists with new entries at the start of the upgrade, and possibly remove some entries when the upgrade is done -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2581) StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2581?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-2581: ----------------------------------- Assignee: Adrian Nistor (was: Dan Berindei) > StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon > --------------------------------------------------------------------------------- > > Key: ISPN-2581 > URL: https://issues.jboss.org/browse/ISPN-2581 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR1 > > > StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns as soon as a joining node confirmed to the coordinator that it received all the data it needed (see STMI.notifyEndOfTopologyUpdate()). > It should return only after the coordinator has confirmed the end of the rebalance with a new topology update (see STMI.doTopologyUpdate()). > This should make it more likely for the tests suite clusters to be in a stable state by the time the test starts, and should help with the random state transfer-related failures in non-state transfer tests. > Instead we should make sure that we do have tests that check forwarding behaviour explicitly. -- 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012