October 2013 - infinispan-issues - Jboss List Archives

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3422: -------------------------------- Labels: jdg62blocker (was: ) > 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 > > 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-3422) In non-tx caches, write operations may not be atomic during rebalance

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3422: -------------------------------- Fix Version/s: 6.0.0.CR2 6.0.0.Final > 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-3617) Inconsistent L1 in non-tx distributed cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3617: -------------------------------- Priority: Critical (was: Major) > Inconsistent L1 in non-tx distributed cache > ------------------------------------------- > > Key: ISPN-3617 > URL: https://issues.jboss.org/browse/ISPN-3617 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.7.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3648: -------------------------------- Labels: jdg62blocker (was: ) > 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-3635) Out of data read after write on node losing ownership

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3635?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3635: -------------------------------- Labels: jdg62blocker (was: ) > Out of data read after write on node losing ownership > ----------------------------------------------------- > > Key: ISPN-3635 > URL: https://issues.jboss.org/browse/ISPN-3635 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, State transfer > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Final > > > In a situation where a node is losing ownership of an entry (during a state transfer), when the node does a write (and commits that), the change is propagated only to the new owners, the entry is not written locally. However, when it executes read for this key afterwards, it gets the old value as this is directly retrieved from the data container. > This bug was observed in transactional mode, but might not be limited to 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, 2 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3617: ------------------------------------- If a non owner updates a value for which it has an L1 value, it removes the value from it's own L1 cache. It isn't done through invalidation like other operations. This is done in L1NonTxInterceptor at line 238. Did you have a case where this wasn't done? > Inconsistent L1 in non-tx distributed cache > ------------------------------------------- > > Key: ISPN-3617 > URL: https://issues.jboss.org/browse/ISPN-3617 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.7.Final > Reporter: Radim Vansa > Assignee: William Burns > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation. -- 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 Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-3618?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-3618: ------------------------------------ The encoding is SQL_Latin1_General_CP1_CI_AS . Microsoft SQL servers don't even support UTF-8. > 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 Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3633: ----------------------------------- This was a transactional cache, with default (read committed) isolation. Here is an excerpt from the logs, the full ones are on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-radargun-resilie... 08:38:28,313 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-21) Key key_000000000000491A modified by a regular tx, state transfer will ignore it 08:38:28,313 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-21) Entry for key key_000000000000491A is null : not calling commitUpdate Then later on, when executing StateResponseCommand: 08:38:45,514 TRACE [org.infinispan.transaction.LocalTransaction] (remote-thread-20) Adding modification PutKeyValueCommand{key=key_000000000000491A, value=[37 #1: 173, ], flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}. Mod list is null 08:38:45,526 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-20) State transfer will not write key/value key_000000000000491A/[37 #1: 173, ] because it was already updated by somebody else Therefore, for reproduction of this bug you need to get to this situation 1. A gets entry from B, caches that 2. state transfer from B to A begins (B is previous owner, A is new one) - some delay or many entries would be required here 3. entry is overwritten on B, invalidating A's record 4. when A get's the StateResponseCommand, the entry is not set 5. you may check the entry on A to be still null Is there anything that should prohibit this behaviour? Am I oversimplifying something? > 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-3652) Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3652?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3652: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 1021479|https://bugzilla.redhat.com/show_bug.cgi?id=1021479] Find the info here: https://issues.jboss.org/browse/ISPN-3652 > Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6 > ----------------------------------------------------------------------------------- > > Key: ISPN-3652 > URL: https://issues.jboss.org/browse/ISPN-3652 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.CR1 > Environment: Windows 2012 && JDK6 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > > The tests for the environment specified hang randomly on package org.infinispan.statetransfer. > Due to not being able to login to executing machine at the moment I cannot provide logs/thread dump for the hanged tests. > The logs would be attached later. -- 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-3652) Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3652?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3652: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021479 > Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6 > ----------------------------------------------------------------------------------- > > Key: ISPN-3652 > URL: https://issues.jboss.org/browse/ISPN-3652 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.CR1 > Environment: Windows 2012 && JDK6 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > > The tests for the environment specified hang randomly on package org.infinispan.statetransfer. > Due to not being able to login to executing machine at the moment I cannot provide logs/thread dump for the hanged tests. > The logs would be attached later. -- 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