January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3877) Disk Space optimizations for SingleFileStore

by Rajesh Jangam (JIRA)

[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ] Rajesh Jangam commented on ISPN-3877: ------------------------------------- The forums link contains the patched version of the file. > Disk Space optimizations for SingleFileStore > -------------------------------------------- > > Key: ISPN-3877 > URL: https://issues.jboss.org/browse/ISPN-3877 > Project: Infinispan > Issue Type: Patch > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64 > Reporter: Rajesh Jangam > Assignee: Mircea Markus > > We are testing the latest Infinispan 6.0 SingleFileStore version for our application. > We tend to create a lot of entries in the store and remove them when not required. > However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed. > > This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed. > We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation. > The proposed fix is twofold: > 1. Truncates the file if there are free fileentries at the end of the data file. > 2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases. > Please review this diff and let us know your opinion -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3877) Disk Space optimizations for SingleFileStore

by Rajesh Jangam (JIRA)

Rajesh Jangam created ISPN-3877: ----------------------------------- Summary: Disk Space optimizations for SingleFileStore Key: ISPN-3877 URL: https://issues.jboss.org/browse/ISPN-3877 Project: Infinispan Issue Type: Patch Components: Loaders and Stores Affects Versions: 6.0.0.Final Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64 Reporter: Rajesh Jangam Assignee: Mircea Markus We are testing the latest Infinispan 6.0 SingleFileStore version for our application. We tend to create a lot of entries in the store and remove them when not required. However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed. This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed. We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation. The proposed fix is twofold: 1. Truncates the file if there are free fileentries at the end of the data file. 2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases. Please review this diff and let us know your opinion -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3421) State Transfer can leave keys on < numOwners nodes for transactional caches.

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3421?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3421: ------------------------------------ I think the problem is that A leaves the cluster before it managed to send the CommitCommand to all the replicas. E.g. B receives the commit, but C doesn't. When C sees a new view without A in it, it deletes all transactions that originated on A in {{TransactionTable.cleanupStaleTransactions()}} (at least if recovery is not enabled). [~an1310], did I get it right? I think fixing this would require changing the CH update that happens after a leave to be done in two phases, just like rebalancing. In the first phase, all the members would install the new CH and would stop accepting commands from the leaver. In the second phase, each member would delete the pending transactions from the leaver, but first it would check with the other owners if they received a commit command. If any owner received the commit, the transaction should be committed, otherwise it should be removed. Enabling recovery may help a bit, since C won't delete transactions originated from A outright, but on the other hand it doesn't keep backup locks for them - new transactions can update the same data while the originator is down, so we still have inconsistencies. > State Transfer can leave keys on < numOwners nodes for transactional caches. > ---------------------------------------------------------------------------- > > Key: ISPN-3421 > URL: https://issues.jboss.org/browse/ISPN-3421 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Priority: Critical > > There's a hole in state transfer mechanism that can occur when a node is leaving the cluster, but it was creating the entries and was only able to replicate the data to some of the nodes. > The problem occurs when the segment ownership of the node doesn't change after the rebalance. Since state transfer does not request state for keys in which it is already an owner, the cache could be left in a state where a key is resident < numOwners nodes. In addition, this could be any subset of the primary OR backup 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3876) TcpTransportFactory stores failed SocketAddress in RequestBalancingStrategy

by Patrick Seeber (JIRA)

Patrick Seeber created ISPN-3876: ------------------------------------ Summary: TcpTransportFactory stores failed SocketAddress in RequestBalancingStrategy Key: ISPN-3876 URL: https://issues.jboss.org/browse/ISPN-3876 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.Final, 5.3.0.Final, 5.2.1.Final Environment: Hotrod Client, Java Reporter: Patrick Seeber Assignee: Mircea Markus The "updateServers" Method in the TcpTransportFactory class iterates over all addedServers and adds them to the connection pool if no exceptions are thrown. Howerver, if an exception is thrown, the SocketAddress may not have been added to the conection pool but is added to the balancer afterwards. Therefore, the balancer may contain an invalid SocketAddress which is not contained in the connection pool. In our application with few distributed caches, we encounter situations where all servers (SocketAddresses) are corrupt and the application fails to load or store entries in/from the cache. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3875) JMX related chapter of user guide is not up to date

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3875?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3875: ------------------------------------- Also, config samples use the old deprecated api. > JMX related chapter of user guide is not up to date > ---------------------------------------------------- > > Key: ISPN-3875 > URL: https://issues.jboss.org/browse/ISPN-3875 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The text implies the user needs to follow certain steps in order to enable jmx (ie enable stats), but mbeans are currently created and registered even if statistics are not enabled. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3745: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1033087|https://bugzilla.redhat.com/show_bug.cgi?id=1033087] from ON_QA to VERIFIED > Forwarded Prepare/Commit executed after transaction finished > ------------------------------------------------------------ > > Key: ISPN-3745 > URL: https://issues.jboss.org/browse/ISPN-3745 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha1 > > > Replicated TX cache, nodes A, B, C > 0. A and B have topology 2, C already got topology 3 > 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond > 2. C forwards prepare to B with topology 3 > 3. A sends commit with topology 2 to B and C, both commit and respond > 4. again, C forwards prepare to B with topology 3 > 5. A and B get updated topology id > 6. A executes another transaction on the same entry > 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again > Result: on B we have inconsistent state -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3704: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1032050|https://bugzilla.redhat.com/show_bug.cgi?id=1032050] from ON_QA to VERIFIED > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha1 > > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > EDIT: > I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3704: ------------------------------ Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/2304 > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha1 > > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > EDIT: > I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Radim Vansa reopened ISPN-3704: ------------------------------- > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha1 > > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > EDIT: > I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3704: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > Fix For: 7.0.0.Alpha1 > > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > EDIT: > I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well. -- 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014