March 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1923) Versioning enabling new-to-old configuration bug

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1923: -------------------------------------- Summary: Versioning enabling new-to-old configuration bug Key: ISPN-1923 URL: https://issues.jboss.org/browse/ISPN-1923 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.2.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.3.CR1, 5.1.3.FINAL There's a bug in the new to old configuration transformation where if we enable versioning with the new config: {code}ConfigurationBuilder builder... builder.versioning().enable().scheme(VersioningScheme.SIMPLE){code} The old configuration fails to catch this and so configuration.isEnableVersioning() returns false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
3
0 / 0

[JBoss JIRA] (ISPN-1901) Use different multicast settings for MPING and UDP

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1901: -------------------------------------- Summary: Use different multicast settings for MPING and UDP Key: ISPN-1901 URL: https://issues.jboss.org/browse/ISPN-1901 Project: Infinispan Issue Type: Task Components: Configuration Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Make default MPING mcast address and port use different values as to UDP configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] (ISPN-1919) L1ConfigurationBuilder should disable onRehash when disabling L1

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-1919: ------------------------------------- Summary: L1ConfigurationBuilder should disable onRehash when disabling L1 Key: ISPN-1919 URL: https://issues.jboss.org/browse/ISPN-1919 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.2.FINAL Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.1.3.CR1, 5.1.3.FINAL The L1ConfigurationBuilder (rightly) breaks when l1 is disabled and l1 onrehash is enabled. Unfortunately when a configuration is inherited via read() from a previous configuration where l1 was enabled (and onrehash enabled implicitly because of this), the user is forced to call L1ConfigurationBuilder.disable().disableOnRehash(), which is a bit redundant. This also breaks AS7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
4
0 / 0

[JBoss JIRA] (ISPN-1902) Cache loader "class" attribute should be xsd:string

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1902: -------------------------------------- Summary: Cache loader "class" attribute should be xsd:string Key: ISPN-1902 URL: https://issues.jboss.org/browse/ISPN-1902 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.2.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
9
0 / 0

[JBoss JIRA] (ISPN-1900) MarshalledValue NPE when unmarshalling preloaded data

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1900: -------------------------------------- Summary: MarshalledValue NPE when unmarshalling preloaded data Key: ISPN-1900 URL: https://issues.jboss.org/browse/ISPN-1900 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.1.2.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL {code}org.infinispan.CacheException: Unable to unmarshall value at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:159) at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:143) at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:224) at org.infinispan.interceptors.MarshalledValueInterceptor.visitEntrySetCommand(MarshalledValueInterceptor.java:256) at org.infinispan.commands.read.EntrySetCommand.acceptVisitor(EntrySetCommand.java:60) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) at org.infinispan.commands.AbstractVisitor.visitEntrySetCommand(AbstractVisitor.java:107) at org.infinispan.commands.read.EntrySetCommand.acceptVisitor(EntrySetCommand.java:60) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:89) at org.infinispan.commands.AbstractVisitor.visitEntrySetCommand(AbstractVisitor.java:107) at org.infinispan.commands.read.EntrySetCommand.acceptVisitor(EntrySetCommand.java:60) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) at org.infinispan.CacheImpl.entrySet(CacheImpl.java:327) at org.infinispan.CacheImpl.entrySet(CacheImpl.java:320) at org.infinispan.loaders.BaseCacheStoreFunctionalTest.testPreloadStoredAsBinary(BaseCacheStoreFunctionalTest.java:166) 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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeMethod(Invoker.java:546) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:909) at org.testng.TestRunner.privateRun(TestRunner.java:618) at org.testng.TestRunner.run(TestRunner.java:499) at org.testng.SuiteRunner.runTest(SuiteRunner.java:332) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299) at org.testng.SuiteRunner.run(SuiteRunner.java:204) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:101) 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: java.lang.NullPointerException at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:154) ... 44 more{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
8
0 / 0

[JBoss JIRA] (ISPN-1911) TestNameVerifier test class in tools submodule should use File.separator in order to work on Windows

by Martin Gencur (JIRA)

Martin Gencur created ISPN-1911: ----------------------------------- Summary: TestNameVerifier test class in tools submodule should use File.separator in order to work on Windows Key: ISPN-1911 URL: https://issues.jboss.org/browse/ISPN-1911 Project: Infinispan Issue Type: Bug Components: Test Suite Reporter: Martin Gencur Assignee: Mircea Markus The following class contains UNIX-style file separators: https://github.com/infinispan/infinispan/blob/master/tools/src/test/java/... We'll be executing the testsuite as a part of JDG release on Windows so it would be good to fix this. Our temporary hudson job for windows shows that the test fails: http://hudson.qa.jboss.com/hudson/job/edg-60-community-testsuite-windows/... Please fix this also in 5.1.x branch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
7
0 / 0

[JBoss JIRA] (ISPN-1914) Add hints for when File.listFiles() returns null

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1914: -------------------------------------- Summary: Add hints for when File.listFiles() returns null Key: ISPN-1914 URL: https://issues.jboss.org/browse/ISPN-1914 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 5.1.2.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL Under some circumstances, File.listFiles() can return null as shown by AS7-3808: {code} @return An array of abstract pathnames denoting the files and directories in the directory denoted by this abstract pathname. The array will be empty if the directory is empty. Returns <code>null</code> if this abstract pathname does not denote a directory, or if an I/O error occurs. {code} In order to get more information, if listFiles() returns null, add some checks to see if File.exists() and if File.isDirectory(). This might give us more of a clue of what happened. Also, although not likely, it might be worth to check permissions via File.canRead() and File.canWrite() too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[JBoss JIRA] (ISPN-1466) Async configuration tag affects communication between cache and HotRod client

by Martin Gencur (Created) (JIRA)

Async configuration tag affects communication between cache and HotRod client ----------------------------------------------------------------------------- Key: ISPN-1466 URL: https://issues.jboss.org/browse/ISPN-1466 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.ALPHA1 Reporter: Martin Gencur Assignee: Manik Surtani When using a REPL (replicated) cache with configuration tag <async useReplQueue="true" replQueueMaxElements="3" replQueueInterval="1000" />, HotRod client cannot see a cache entry which was just stored into a cache. The entry is visible not before the replication queue is flushed (either because of MaxElements limit or QueueInterval). I'll attach a testcase but here's a test snippet that fails at first assert: {code} @Test public void testQueueSize() throws Exception { RemoteCache<String, String> asyncCache1 = rcm1.getCache(asyncCacheSize); RemoteCache<String, String> asyncCache2 = rcm2.getCache(asyncCacheSize); asyncCache1.clear(); asyncCache1.put("k1", "v1"); assertTrue(null != asyncCache1.get("k1")); assertTrue(null == asyncCache2.get("k2")); asyncCache1.put("k2", "v2"); //k3 fills up the queue -> flush asyncCache1.put("k3", "v3"); Thread.sleep(1000); //wait for the queue to be flushed assertTrue(null != asyncCache1.get("k1")); assertTrue(null != asyncCache2.get("k2")); } {code} IMO when I have cache A and B in a cluster and the cache entry is stored into the cache A, it should be visible at A and not in B. After flushing the queue it should be visible also at B. Here's the test: https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes... (to run it, one has to install infinispan-arquillian-container into local maven repository, set ISPN_HOME pointing to Infinispan distribution and run "mvn clean verify") -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

9
36
0 / 0

[JBoss JIRA] Created: (ISPN-1318) replaceWithVersionAsync on RemoteCache (HotRod) fails to set lifespan of cache entries

by Martin Gencur (JIRA)

replaceWithVersionAsync on RemoteCache (HotRod) fails to set lifespan of cache entries -------------------------------------------------------------------------------------- Key: ISPN-1318 URL: https://issues.jboss.org/browse/ISPN-1318 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.FINAL Reporter: Martin Gencur Assignee: Manik Surtani Cache entries remain in the cache even after their lifespan expires (when setting the lifespan via replaceWithVersionAsync and also via replaceWithVersion (sync)) The test verifying this can be found at https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes... - test method testReplaceWithVersionWithLifespanAsync() The test is failing on line assertEquals(null, cache.getVersioned("aKey")); To run it, one has to set ISPN_HOME property pointing to Infinispan build and run "mvn clean verify". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

8
13
0 / 0

[JBoss JIRA] (ISPN-1913) TransactionTable warning very verbose

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1913: ----------------------------------- Summary: TransactionTable warning very verbose Key: ISPN-1913 URL: https://issues.jboss.org/browse/ISPN-1913 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.1.2.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.x See AS7-4145 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2012