January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2574: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 882162|https://bugzilla.redhat.com/show_bug.cgi?id=882162] from ON_QA to VERIFIED > Segment transfer not restarted if the owner fails > ------------------------------------------------- > > Key: ISPN-2574 > URL: https://issues.jboss.org/browse/ISPN-2574 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR3 > > > Imagine this situation in distributed cache with 3 owners: > 1) The segment X is owned by nodes A, B, C > 2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted > 3) Node D starts transfer of segment X from C > 4) Node C fails -> another CH_UPDATE is broadcasted > 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A > The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2574: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 882162|https://bugzilla.redhat.com/show_bug.cgi?id=882162] StateTransferRestartTest that fails in ER9 passes in ER10. > Segment transfer not restarted if the owner fails > ------------------------------------------------- > > Key: ISPN-2574 > URL: https://issues.jboss.org/browse/ISPN-2574 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR3 > > > Imagine this situation in distributed cache with 3 owners: > 1) The segment X is owned by nodes A, B, C > 2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted > 3) Node D starts transfer of segment X from C > 4) Node C fails -> another CH_UPDATE is broadcasted > 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A > The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2712) Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2712?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2712: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2712 > URL: https://issues.jboss.org/browse/ISPN-2712 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.CR1 > Reporter: Randall Hauch > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.Final > > Attachments: ispn_eviction_log.txt, spectrum-repository-infinispan.xml > > > Using a clustered cache with 2 nodes, where the cache in each node is configured identically with replication, eviction and (non-shared) file cache store. (See attached configuration.) > The first (coordinator) process in the cluster is started and populated with 293 entries. Then the first process continually adds a few entries every 5 seconds. After a short delay, the second process is started, at which point it joins the cluster and starts the state-transfer process; logging shows in the first process that all 293 entries are transferred to the new cluster member, and the second log shows that they are all received. The second process then attempts to look for a specific entry that was created during initial population in the first process. This fails to find the existing entry. > By enabling trace logging and "IDE breakpoint output messages" around state transfer, it's visible that from the 293 keys, only 218 are placed into the cache, the others being lost. > (This problem was originally discovered when clustering ModeShape, which behaves roughly in the manner described above. The initial entries that are populated upon initialization are content created when a new repository is started. The second process looks for this content, and if it finds the content it knows not to create all of this initial content. However, if it doesn't find it, it thinks the repository has not yet been initialized and that it should create the initial content. The problem described by this bug then manifests itself in ModeShape through dozens of exceptions because the repository has been corrupted. See MODE-1745 for details on this problem. ModeShape's corresponding known issue for this issue, ISPN-2712, is MODE-1754.) > The eviction is configured like this: > {code:xml} > <eviction strategy="LIRS" maxEntries="1000"/> > {code} > The attached log file is from the second process (the "receiver" node) and it contains the following key points: > * line 40 - the total number of keys & entries to be transferred = 293 > * line 1352 and from there onwards 1358 / 1364 / i + 6 - the data container's size stops growing at 218, while the other entries are being sent. This means that in effect, they are ignored. > * line 1797 - the loop from {{org.infinispan.statetransfer.StateConsumerImpl#doApplyState}} finishes > Disabling eviction fixes the problem and all 293 nodes are placed in Node2's cache. > (I initially marked this as CRITICAL priority, though it is a blocker for our use of Infinispan 5.2.) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2764) DataRehashEvent with pre == false has null getConsistentHashAtEnd()

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2764?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2764: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > DataRehashEvent with pre == false has null getConsistentHashAtEnd() > ------------------------------------------------------------------- > > Key: ISPN-2764 > URL: https://issues.jboss.org/browse/ISPN-2764 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 5.2.0.CR3 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.2.0.Final > > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2150) Data Rehash Event: getMembersAtStart/End returns empty set

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2150?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2150: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Data Rehash Event: getMembersAtStart/End returns empty set > ---------------------------------------------------------- > > Key: ISPN-2150 > URL: https://issues.jboss.org/browse/ISPN-2150 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Listeners, State transfer > Affects Versions: 5.1.5.FINAL > Environment: 5.2.0-SNAPSHOT master branch > Reporter: Pedro Ruivo > Assignee: Adrian Nistor > Labels: DataRehash, DateRehashEvent, Listener > Fix For: 5.2.0.Final > > > When the event is trigger the getMembersAtStart/End() returns an empty set. > A test case can be found in here [1] and you can integrate it in the master if you want. =) > Cheers > [1] https://github.com/pruivo/infinispan/blob/data_rehash_event/core/src/test... -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2662) Invalid formatting character in TxCompletionNotificationCommand

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2662?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2662: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Invalid formatting character in TxCompletionNotificationCommand > --------------------------------------------------------------- > > Key: ISPN-2662 > URL: https://issues.jboss.org/browse/ISPN-2662 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Minor > Fix For: 5.2.0.Final > > > Trace logging reveals that in {{org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.forwardCommandRemotely}} is a typo - {{%w}} instead of {{%s}} -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2774) ClientSocketReadTimeoutTest takes more than 3 minutes to run

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2774?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2774: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1623 Open the latch before shutting down the cache manager, as the test framework tries to stop individual caches first. > ClientSocketReadTimeoutTest takes more than 3 minutes to run > ------------------------------------------------------------ > > Key: ISPN-2774 > URL: https://issues.jboss.org/browse/ISPN-2774 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 5.2.0.Final > > > The test uses a cache manager to block getCache() calls and provoke client read timeouts, but then it calls getCache() itself during shutdown and has to wait for 3 minutes. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2773) Can't access a non-clustered cache via HotRod

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2773?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2773: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1623 Check for a null RpcManager in AbstraceEncoder1x.getTopologyResponse. > Can't access a non-clustered cache via HotRod > --------------------------------------------- > > Key: ISPN-2773 > URL: https://issues.jboss.org/browse/ISPN-2773 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.2.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.Final > > > With the ISPN-2632 fix, we switched from using the JGroups view id as a HotRod topology id, to using the topology id of the cache being accessed. > If the cache isn't clustered, however, it doesn't have a RpcManager and attempting to read the cache's topology id results in a NullPointerException: > {noformat} > java.lang.NullPointerException > at org.infinispan.server.hotrod.AbstractEncoder1x.getTopologyResponse(AbstractEncoder1x.scala:160) > at org.infinispan.server.hotrod.AbstractEncoder1x.writeHeader(AbstractEncoder1x.scala:49) > at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:63) > at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66) > at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) > at org.jboss.netty.channel.Channels.write(Channels.java:704) > at org.jboss.netty.channel.Channels.write(Channels.java:671) > at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) > at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:179) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:157) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:105) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:70) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:47) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:387) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > {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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2774) ClientSocketReadTimeoutTest takes more than 3 minutes to run

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2774: ---------------------------------- Summary: ClientSocketReadTimeoutTest takes more than 3 minutes to run Key: ISPN-2774 URL: https://issues.jboss.org/browse/ISPN-2774 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.2.0.CR3 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 5.2.0.Final The test uses a cache manager to block getCache() calls and provoke client read timeouts, but then it calls getCache() itself during shutdown and has to wait for 3 minutes. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2739) Incorrect help for "encoding" command

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2739?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2739: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 902821|https://bugzilla.redhat.com/show_bug.cgi?id=902821] from ON_QA to VERIFIED > Incorrect help for "encoding" command > -------------------------------------- > > Key: ISPN-2739 > URL: https://issues.jboss.org/browse/ISPN-2739 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 5.2.0.CR2 > Reporter: Martin Gencur > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 5.2.0.CR3 > > > The help for "encoding" command shows the following: > SYNOPSIS > encoding [cachename] > DESCRIPTION > Shows the currently selected cache or selects a cache to be used as default for CLI operations > ARGUMENTS > cachename > (optional) the name of the cache to set as default for the following operations -- 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013