[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3680:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1087205|https://bugzilla.redhat.com/show_bug.cgi?id=1087205] from NEW to MODIFIED
> 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, 5.2.9.Final
>
>
> 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
10 years, 2 months
[JBoss JIRA] (ISPN-3689) Preloading fails with JdbcBinaryCacheStore on DB2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3689?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3689:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1087209|https://bugzilla.redhat.com/show_bug.cgi?id=1087209] from NEW to MODIFIED
> 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, 5.2.9.Final
>
>
> 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
10 years, 2 months
[JBoss JIRA] (ISPN-3849) Re-work ServiceLoader concepts
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3849?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3849:
----------------------------
Fix Version/s: 7.0.0.Alpha4
> Re-work ServiceLoader concepts
> ------------------------------
>
> Key: ISPN-3849
> URL: https://issues.jboss.org/browse/ISPN-3849
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 7.0.0.Alpha4
>
>
> Any uses of ServiceLoader will need to be replaced by a new utility to first check OSGi services w/ SL as a fallback. This also requires that any internal services also need to be registered with OSGi (as well as external extension point impls, etc.). That's not invasive at all. OSGi blueprint files are very similar to the service loader text files in META-INF/services.
--
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, 2 months
[JBoss JIRA] (ISPN-3850) Introduce non-static utility to handle classloading hierarchy
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3850?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3850:
----------------------------
Fix Version/s: 7.0.0.Alpha4
> Introduce non-static utility to handle classloading hierarchy
> -------------------------------------------------------------
>
> Key: ISPN-3850
> URL: https://issues.jboss.org/browse/ISPN-3850
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 7.0.0.Alpha4
>
>
> In Commons, the FileLookup and CL concepts within Util need replaced by a non-static/non-singleton classloading service. This will run through the following sequence, in order:
> 1.) OsgiClassLoader (new)
> 2.) explicit classloader (provided per-operation by AdvancedCache#with(ClassLoader))
> 3.) Infinispan CL
> 4.) system CL
> 5.) TCCL
> Since it's not static/singleton, the util instance will need wired into GlobalConfiguration (or elsewhere). The instance will replace the related Util/FileLookup calls.
--
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, 2 months
[JBoss JIRA] (ISPN-3849) Re-work ServiceLoader concepts
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3849?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3849:
----------------------------
Status: Closed (was: Pull Request Sent)
Resolution: Done
> Re-work ServiceLoader concepts
> ------------------------------
>
> Key: ISPN-3849
> URL: https://issues.jboss.org/browse/ISPN-3849
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 7.0.0.Alpha4
>
>
> Any uses of ServiceLoader will need to be replaced by a new utility to first check OSGi services w/ SL as a fallback. This also requires that any internal services also need to be registered with OSGi (as well as external extension point impls, etc.). That's not invasive at all. OSGi blueprint files are very similar to the service loader text files in META-INF/services.
--
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, 2 months
[JBoss JIRA] (ISPN-3850) Introduce non-static utility to handle classloading hierarchy
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3850?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-3850:
----------------------------
Status: Closed (was: Pull Request Sent)
Resolution: Done
> Introduce non-static utility to handle classloading hierarchy
> -------------------------------------------------------------
>
> Key: ISPN-3850
> URL: https://issues.jboss.org/browse/ISPN-3850
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 7.0.0.Alpha4
>
>
> In Commons, the FileLookup and CL concepts within Util need replaced by a non-static/non-singleton classloading service. This will run through the following sequence, in order:
> 1.) OsgiClassLoader (new)
> 2.) explicit classloader (provided per-operation by AdvancedCache#with(ClassLoader))
> 3.) Infinispan CL
> 4.) system CL
> 5.) TCCL
> Since it's not static/singleton, the util instance will need wired into GlobalConfiguration (or elsewhere). The instance will replace the related Util/FileLookup calls.
--
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, 2 months
[JBoss JIRA] (ISPN-4187) LRU eviction algorithm does not evict the eldest entry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4187?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4187:
-----------------------------------------------
William Burns <wburns(a)redhat.com> changed the Status of [bug 1090591|https://bugzilla.redhat.com/show_bug.cgi?id=1090591] from NEW to POST
> LRU eviction algorithm does not evict the eldest entry
> ------------------------------------------------------
>
> Key: ISPN-4187
> URL: https://issues.jboss.org/browse/ISPN-4187
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 7.0.0.Alpha2
> Reporter: Martin Gencur
> Assignee: William Burns
> Attachments: server2.log
>
>
> The following test for JDBC cache stores fails:
> {code:java}
> @Test
> @WithRunningServer({@RunningServer(name = CONTAINER1, config = CONFIG_FETCH_STATE_1)})
> public void testFetchState() throws Exception {
> try {
> mc1 = createMemcachedClient(server1);
> assertCleanCacheAndStore1();
> mc1.set("k1", "v1");
> mc1.set("k2", "v2");
> mc1.set("k3", "v3");
> assertNotNull(dbServer1.stringTable.getValueByKey("k1"));
> startContainer(controller, CONTAINER2, CONFIG_FETCH_STATE_2);
> mc2 = createMemcachedClient(server2);
> assertTrue(0 < server2.getCacheManager(MANAGER_NAME).getCache(CACHE_NAME).getNumberOfEntries());
> //the cache store should fetch state from the others
> //since eviction.max-entries==2, first k2 and k3 is loaded from the other cache, then k1 is loaded
> //from the other cache's loader and thus k2 is evicted and ends up in a cache loader
> assertNull(dbServer2.stringTable.getValueByKey("k1"));
> assertEquals("v1", mc2.get("k1"));
> assertEquals("v2", mc2.get("k2"));
> assertNull(dbServer2.stringTable.getValueByKey("k1"));
> //^^^^^fails here, the K1 was evicted even though it was used recently
> //K3 was supposed to be evicted but it did not happen
> assertNull(dbServer2.stringTable.getValueByKey("k2"));
> assertCleanCacheAndStore2();
> } finally {
> controller.stop(CONTAINER2);
> }
> }
> {code}
> This tests works properly if the following commit is reverted, so it was caused by this commit:
> https://github.com/infinispan/infinispan/commit/b190230d84beb41474bae0239...
> Note that there's another commit with the same name but different commit hash: b71da1c
> The test above can be run from https://github.com/chepa653/infinispan/tree/t_ISPN-3904 by going to server/integration/testsuite and running mvn clean verify -Dtest=StringBasedStoreMultinodeTest#testFetchState -Dlog.level.infinispan=TRACE
--
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, 2 months