April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3920: ----------------------------------- I am not sure this was resolved completely - when I restart the server in qemu-kvm (using single processor), I occasionally see errors from the logging subsystem (such as that some handler was not defined). Nevertheless, for JDG subsystems it appears to work. > Server initialization race condition - cache config defaults not used > --------------------------------------------------------------------- > > Key: ISPN-3920 > URL: https://issues.jboss.org/browse/ISPN-3920 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Ion Savin > Assignee: Ion Savin > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: server.log.gz > > > The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. > The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- 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-4215) Synchronize series in report by date

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4215?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-4215. ----------------------------- Resolution: Rejected > Synchronize series in report by date > ------------------------------------ > > Key: ISPN-4215 > URL: https://issues.jboss.org/browse/ISPN-4215 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Minor > > If I have two series; series A with 3 executions on 1st April, 5th April and 10th April, and series B with 2 executions on 2nd April and 12th April, the charts will be as A having datapoints at 0 - 2, and B having datapoints at 0 and 1. > I'd prefer A to have datapoints 0, 2 and 3, and B having datapoints 1 and 4. The line in chart should ignore non-existent datapoints and go directly to the next execution. -- 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-4215) Synchronize series in report by date

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4215?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-4215: ----------------------------------- Oops, JIRA to the wrong project... > Synchronize series in report by date > ------------------------------------ > > Key: ISPN-4215 > URL: https://issues.jboss.org/browse/ISPN-4215 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Minor > > If I have two series; series A with 3 executions on 1st April, 5th April and 10th April, and series B with 2 executions on 2nd April and 12th April, the charts will be as A having datapoints at 0 - 2, and B having datapoints at 0 and 1. > I'd prefer A to have datapoints 0, 2 and 3, and B having datapoints 1 and 4. The line in chart should ignore non-existent datapoints and go directly to the next execution. -- 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-4220) RemoteCacheManager.getCache may ignore the forceReturnValue flag

by Radim Vansa (JIRA)

Radim Vansa created ISPN-4220: --------------------------------- Summary: RemoteCacheManager.getCache may ignore the forceReturnValue flag Key: ISPN-4220 URL: https://issues.jboss.org/browse/ISPN-4220 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Assignee: Mircea Markus {code} RemoteCacheManager manager = ...; Cache noReturnCache = manager.getCache("foo", false); Cache returnValueCache = manager.getCache("foo", true); {code} The second returned cache will use forceReturnValue=false, although it was retrieved with forceReturnValue=true. The reason is that caches are stored in a map by name, ignoring this flag. There should be two such maps. The question is what should getCache("foo") return if previously only getCache("foo", true) was called. -- 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-4220) RemoteCacheManager.getCache may ignore the forceReturnValue flag

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4220?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4220: ------------------------------ Assignee: Galder Zamarreño (was: Mircea Markus) > RemoteCacheManager.getCache may ignore the forceReturnValue flag > ---------------------------------------------------------------- > > Key: ISPN-4220 > URL: https://issues.jboss.org/browse/ISPN-4220 > Project: Infinispan > Issue Type: Bug > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > {code} > RemoteCacheManager manager = ...; > Cache noReturnCache = manager.getCache("foo", false); > Cache returnValueCache = manager.getCache("foo", true); > {code} > The second returned cache will use forceReturnValue=false, although it was retrieved with forceReturnValue=true. The reason is that caches are stored in a map by name, ignoring this flag. > There should be two such maps. The question is what should getCache("foo") return if previously only getCache("foo", true) was called. -- 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-4220) RemoteCacheManager.getCache may ignore the forceReturnValue flag

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4220?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4220: ------------------------------ Component/s: Remote Protocols > RemoteCacheManager.getCache may ignore the forceReturnValue flag > ---------------------------------------------------------------- > > Key: ISPN-4220 > URL: https://issues.jboss.org/browse/ISPN-4220 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > {code} > RemoteCacheManager manager = ...; > Cache noReturnCache = manager.getCache("foo", false); > Cache returnValueCache = manager.getCache("foo", true); > {code} > The second returned cache will use forceReturnValue=false, although it was retrieved with forceReturnValue=true. The reason is that caches are stored in a map by name, ignoring this flag. > There should be two such maps. The question is what should getCache("foo") return if previously only getCache("foo", true) was called. -- 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-4220) RemoteCacheManager.getCache may ignore the forceReturnValue flag

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4220?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4220: ------------------------------ Affects Version/s: 7.0.0.Alpha3 6.0.2.Final > RemoteCacheManager.getCache may ignore the forceReturnValue flag > ---------------------------------------------------------------- > > Key: ISPN-4220 > URL: https://issues.jboss.org/browse/ISPN-4220 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.2.Final, 7.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > {code} > RemoteCacheManager manager = ...; > Cache noReturnCache = manager.getCache("foo", false); > Cache returnValueCache = manager.getCache("foo", true); > {code} > The second returned cache will use forceReturnValue=false, although it was retrieved with forceReturnValue=true. The reason is that caches are stored in a map by name, ignoring this flag. > There should be two such maps. The question is what should getCache("foo") return if previously only getCache("foo", true) was called. -- 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-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3680: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Inconsistent way to use the column id in the JdbcBinaryCacheStore > ----------------------------------------------------------------- > > Key: ISPN-3680 > URL: https://issues.jboss.org/browse/ISPN-3680 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4 > > > I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id). -- 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-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3680: ------------------------------- Status: Pull Request Sent (was: Open) > Inconsistent way to use the column id in the JdbcBinaryCacheStore > ----------------------------------------------------------------- > > Key: ISPN-3680 > URL: https://issues.jboss.org/browse/ISPN-3680 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4 > > > I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id). -- 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-3689) Preloading fails with JdbcBinaryCacheStore on DB2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3689?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3689: ------------------------------- Status: Pull Request Sent (was: Open) > Preloading fails with JdbcBinaryCacheStore on DB2 > -------------------------------------------------- > > Key: ISPN-3689 > URL: https://issues.jboss.org/browse/ISPN-3689 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final, 6.0.0.CR1 > Environment: DB2 9.7.5 > Reporter: Nicolas Filotto > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4 > > > I use the {{JdbcBinaryCacheStore}} with preloading enabled, when I test it on DB2 I get an exception of type: > {code} > 06.11.2013 16:27:51 *ERROR* [main] DataManipulationHelper: ISPN008007: SQL error while fetching all StoredEntries (DataManipulationHelper.java, line 253) > com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=?;r_quota" FETCH FIRST;<space>, DRIVER=4.13.80 > at com.ibm.db2.jcc.am.id.a(id.java:677) > at com.ibm.db2.jcc.am.id.a(id.java:60) > at com.ibm.db2.jcc.am.id.a(id.java:127) > at com.ibm.db2.jcc.am.fo.c(fo.java:2653) > at com.ibm.db2.jcc.am.fo.d(fo.java:2641) > at com.ibm.db2.jcc.am.fo.a(fo.java:2090) > at com.ibm.db2.jcc.am.go.a(go.java:7639) > at com.ibm.db2.jcc.t4.cb.h(cb.java:141) > at com.ibm.db2.jcc.t4.cb.b(cb.java:41) > at com.ibm.db2.jcc.t4.q.a(q.java:32) > at com.ibm.db2.jcc.t4.sb.i(sb.java:135) > at com.ibm.db2.jcc.am.fo.ib(fo.java:2059) > at com.ibm.db2.jcc.am.go.sc(go.java:3555) > at com.ibm.db2.jcc.am.go.b(go.java:4344) > at com.ibm.db2.jcc.am.go.fc(go.java:741) > at com.ibm.db2.jcc.am.go.executeQuery(go.java:711) > at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at org.infinispan.loaders.jdbc.DataManipulationHelper.loadSome(DataManipulationHelper.java:245) > at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.loadLockSafe(JdbcBinaryCacheStore.java:312) > at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:167) > at org.infinispan.loaders.CacheLoaderManagerImpl.loadState(CacheLoaderManagerImpl.java:285) > at org.infinispan.loaders.CacheLoaderManagerImpl.preload(CacheLoaderManagerImpl.java:238) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217) > at org.infinispan.CacheImpl.start(CacheImpl.java:582) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545) > {code} > I looks like you cannot use a parameter to set your query limit in case of DB2 9.7.5 at least -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014