November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3497) getCountRowsSql() has wrong SQL syntax

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3497?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3497: -------------------------------- Labels: 620 (was: jdg62blocker) > getCountRowsSql() has wrong SQL syntax > -------------------------------------- > > Key: ISPN-3497 > URL: https://issues.jboss.org/browse/ISPN-3497 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Vitalii Chepeliuk > Assignee: Mircea Markus > Labels: 620 > Fix For: 6.0.0.Beta2 > > > When I run tests with mysql database following exception is thrown > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `mix_str____defaultcache`' at line 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4120) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4052) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2503) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2664) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2794) > at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155) > at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322) > at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462) > at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedStore.size(JdbcStringBasedStore.java:358) > {code:title=TableManipulation.java|borderStyle=solid} > public String getCountRowsSql() { > if (countRowsSql == null) { > countRowsSql = "SELECT COUNT (*) FROM " + getTableName(); <<< here should be COUNT(*) without space > } > return countRowsSql; > } > {code} > MySQL is complaining when there is SPACE between COUNT and (*) > >[Error] Script lines: 5-6 -------------------------- > You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `edg_string____defaultcache`' at line 1 -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3504: -------------------------------- Labels: 620 (was: jdg62blocker) > LevelDB Cache store in server doesn't keep data between restarts > ---------------------------------------------------------------- > > Key: ISPN-3504 > URL: https://issues.jboss.org/browse/ISPN-3504 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Labels: 620 > Fix For: 6.0.0.Beta2 > > > I have config with passivation="false" purge="false" > and expect data to survive restarts which doesn't happen. > {code} > <cache-container name="default" default-cache="default" > listener-executor="infinispan-listener"> > <local-cache name="default" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <leveldb-store path="temp-leveldb" block-size="1024" > cache-size="50000" clear-threshold="100000" passivation="false" > purge="false" > > <expiration path="temp-leveldb-expired" queue-size="2000" /> > <compression type="SNAPPY" /> > <implementation type="JAVA" /> > </leveldb-store> > </local-cache> > <local-cache name="memcachedCache" start="EAGER" batching="false"> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" > concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > </local-cache> > </cache-container> > {code} > failing test: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....; > hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798 > for JDG 6.2.0.DR4 -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3507) EntrySet operation in cache with LevelDB store ignores expiration

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3507?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3507: -------------------------------- Labels: 620 (was: jdg62blocker) > EntrySet operation in cache with LevelDB store ignores expiration > ----------------------------------------------------------------- > > Key: ISPN-3507 > URL: https://issues.jboss.org/browse/ISPN-3507 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Beta2 > > > In cache with leveldb cache store, expired entry still appears in collection returned by entrySet operation. > test: > https://github.com/mlinhard/infinispan-cachestore-leveldb/commit/71b62c19... -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3600: -------------------------------- Labels: 620 (was: jdg62blocker) > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores 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

10 years, 6 months

1
0
0 / 0

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

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3617: -------------------------------- Labels: 620 (was: jdg62blocker) > 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: 620 > 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3603: -------------------------------- Labels: 620 (was: jdg62blocker) > Conditional command is committed on originator when it fails on primary owner > ----------------------------------------------------------------------------- > > Key: ISPN-3603 > URL: https://issues.jboss.org/browse/ISPN-3603 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway. > Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient. -- 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

10 years, 6 months

1
0
0 / 0

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

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3648: -------------------------------- Labels: 620 (was: jdg62blocker) > 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: 620 > > 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3635) Out of data read after write on node losing ownership

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3635?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3635: -------------------------------- Labels: 620 (was: jdg62blocker) > 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: 620 > 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-2342: ------------------------------ Labels: (was: jdg62) > The x-site implementation needs an inter-site state transfer mechanism > ---------------------------------------------------------------------- > > Key: ISPN-2342 > URL: https://issues.jboss.org/browse/ISPN-2342 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Reporter: Erik Salter > Assignee: Erik Salter > > To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys. > Note that initially, this should a manual process that is invoked on one site to one of its configured backups. > This should be based on the non-blocking state transfer mechanism for consistency. > The pseudo-design may look similar to the following: > - Manually invokable, background thread > - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner. > - Iterate through the key set. > - If the key has already been modified since the process started, discard. > - Else synchronously write the key value in a TX context -- 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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3396: ------------------------------ Labels: dm (was: jdg620_dm) > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: dm > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013