October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3422: ----------------------------------- Are there any ideas how to solve this issue? I am rather curious about it. > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- > > Key: ISPN-3422 > URL: https://issues.jboss.org/browse/ISPN-3422 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification. > Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible: > {code} > thread 1: putIfAbsent(k, v1) -> null > thread 2: putIfAbsent(k, v2) -> null > {code} -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3618) Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3618?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-3618: ------------------------------------- The solution/workaround could be to convert the UTF-8 data to UCS-2 which is supported by MS SQL server, but only if MS SQL server is used. Otherwise UTF-8 could remain. > Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2 > --------------------------------------------------------------------- > > Key: ISPN-3618 > URL: https://issues.jboss.org/browse/ISPN-3618 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 6.0.0.CR1 > Reporter: Jakub Markos > Assignee: Mircea Markus > Attachments: server_mssql2012_mysql55.log.zip > > > When using this configuration: > {code:xml} > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="READ_COMMITTED" acquire-timeout="20000" concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <eviction strategy="LRU" max-entries="2"/> > <string-keyed-jdbc-store name="defaultStoreName" datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false"> > <string-keyed-table prefix="EDG_STRING"> > <id-column name="id" type="VARCHAR(255)"/> > <data-column name="datum" type="VARBINARY(1000)"/> > <timestamp-column name="version" type="BIGINT"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </local-cache> > {code} > and running this code: > {code} > RemoteCache<Object, Object> cache = new RemoteCacheManager(conf).getCache(); > cache.clear(); > cache.put(new Double(10), new Double(10)); > cache.put(new Double(20), new Double(20)); > cache.put(new Double(30), new Double(30)); // key 10 is evicted > System.out.println(cache.get(new Double(10))); > System.out.println(cache.get(new Double(20))); > System.out.println(cache.get(new Double(30))); > {code} > output: > {quote} > null > 20.0 > 30.0 > {quote} > Attached are logs for mssql2012 and mysql55 (where it works). -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3618) Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3618?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-3618: ------------------------------------- Yeah, the Microsoft SQL server does not seem to support UTF-8. It means that for string-based cache stores only "String" can be used as a key. The other types (coverted with Key2StringMapper) cannot. AFAIK, it also means that string-based cache store cannot be used at all if data is stored via HotRod. That's because HotRod does not send plain strings. > Cannot retrieve evicted entries from Microsoft SQL Server 2012/2008R2 > --------------------------------------------------------------------- > > Key: ISPN-3618 > URL: https://issues.jboss.org/browse/ISPN-3618 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 6.0.0.CR1 > Reporter: Jakub Markos > Assignee: Mircea Markus > Attachments: server_mssql2012_mysql55.log.zip > > > When using this configuration: > {code:xml} > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="READ_COMMITTED" acquire-timeout="20000" concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <eviction strategy="LRU" max-entries="2"/> > <string-keyed-jdbc-store name="defaultStoreName" datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false"> > <string-keyed-table prefix="EDG_STRING"> > <id-column name="id" type="VARCHAR(255)"/> > <data-column name="datum" type="VARBINARY(1000)"/> > <timestamp-column name="version" type="BIGINT"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </local-cache> > {code} > and running this code: > {code} > RemoteCache<Object, Object> cache = new RemoteCacheManager(conf).getCache(); > cache.clear(); > cache.put(new Double(10), new Double(10)); > cache.put(new Double(20), new Double(20)); > cache.put(new Double(30), new Double(30)); // key 10 is evicted > System.out.println(cache.get(new Double(10))); > System.out.println(cache.get(new Double(20))); > System.out.println(cache.get(new Double(30))); > {code} > output: > {quote} > null > 20.0 > 30.0 > {quote} > Attached are logs for mssql2012 and mysql55 (where it works). -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-3633 at 10/22/13 7:39 PM: --------------------------------------------------------------- In my test the command was forwarded to the new owner, but I need to dig further still. was (Author: william.burns): In my test the command was forwarded to A, but I need to dig further still. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- In my test the command was forwarded to A, but I need to dig further still. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3592: ----------------------------------------------- Sanne Grinovero <sanne(a)redhat.com> made a comment on [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097] Thanks! glad this is covered. > Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration > ------------------------------------------------------------------------------- > > Key: ISPN-3592 > URL: https://issues.jboss.org/browse/ISPN-3592 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 6.0.0.CR1 > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Blocker > Fix For: 6.0.0.Final > > > The problem is a very recent regression, so relative to 6.0.0.CR1 only. > {noformat} > java.lang.NullPointerException > at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160) > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605) > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359) > at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483) > at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891) > at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455) > at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434) > at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375) > at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508) > at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695) > at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58) > {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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Work on ISPN-3633 started by William Burns. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3648: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2174 > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg62blocker > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Work on ISPN-3633 stopped by William Burns. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3648: ------------------------------------- Actually this is also an exact match for ISPN-3426 > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg62blocker > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013