October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8198) RocksDB should not call System.gc() on non-windows systems

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-8198?page=com.atlassian.jira.plugin.... ] Ryan Emerson reassigned ISPN-8198: ---------------------------------- Assignee: Tristan Tarrant (was: Ryan Emerson) > RocksDB should not call System.gc() on non-windows systems > ---------------------------------------------------------- > > Key: ISPN-8198 > URL: https://issues.jboss.org/browse/ISPN-8198 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.CR3 > > > https://github.com/infinispan/infinispan/blob/f9b69a95a610b7bd3a8c31b509b... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on IPROTO-120: -------------------------------------- I'd rather add a new boolean flag in ProtoField annotation than piggyback on the defaultValue. Something like {code}boolean strictDefaults() default false;{code}. Turning that on would apply all rules laid out by the spec (which means empty string, 0 numerics, empty collections, etc...). When this is turned off (default behaviour) we'll get nulls. And if the field is not nullable (int vs Integer) we'll throw an error at annotation processing time. Also, if the field is required=true we'll reject use of strictDefaults and defaultValue because they cannot effectively do anything. This will also be consistent with 4.2.x behaviour, so we do not have to publicly apologize for it. But some might question why isnt's this behaviour the default one. Because ... compatibility :) > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Ryan Emerson commented on IPROTO-120: ------------------------------------- I agree that returning an empty String instead of null is horrible! My preference would be for us to be consistent. If we return null for String, Instant and Date, we should also do the same for a collection. I do like the idea of making the null/empty collection behaviour configurable though. Could we make use of the {{ProtoField.defaultValue}} field for collections? "null" returns a null collection and "empty" returns an empty one? I don't mind what the actual strings are, but we could make it a bit more user friendly by utilising String constants. Maybe something like {{ProtobufUtil.NULL_COLLECTION}} and {{ProtobufUtil.EMPTY_COLLECTION}}. > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on IPROTO-120: -------------------------------------- Another thing to consider: the reverse problem will also happen if we decide to revert IPROTO-64: empty collections will be marshalled identically to nulls. and when unmarshalling back you will get a null instead of empty. For the query tests, I'd suggest leaving the marshalling to Serializable where we have such issues. > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10698) Remove InternalDataContainerAdapter

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10698?page=com.atlassian.jira.plugin... ] Dan Berindei commented on ISPN-10698: ------------------------------------- Maybe we can also remove {{AbstractDelegatingDataContainer}} with it? > Remove InternalDataContainerAdapter > ----------------------------------- > > Key: ISPN-10698 > URL: https://issues.jboss.org/browse/ISPN-10698 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Will Burns > Priority: Major > > The InternalDataContainerAdapter class was originally added for when a user could define a custom data container. Now that this has been removed, we no longer need the class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6299) Create docker image to do releases

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6299?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-6299. --------------------------------- Resolution: Done This has been resolved with the provisioning of CI agents through ansible script and the Infinispan release job. > Create docker image to do releases > ---------------------------------- > > Key: ISPN-6299 > URL: https://issues.jboss.org/browse/ISPN-6299 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Priority: Major > > This would allow to do a release from any machine (linux, macos, windows) and avoid key management, ansible and cloud machines -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3427) LevelDB Cache store testsuite failure on Windows 2008

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-3427?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-3427. --------------------------------- Resolution: Out of Date LevelDB has been replaced with RocksDB > LevelDB Cache store testsuite failure on Windows 2008 > ----------------------------------------------------- > > Key: ISPN-3427 > URL: https://issues.jboss.org/browse/ISPN-3427 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Michal Linhard > Priority: Major > > method: org.infinispan.loaders.leveldb.LevelDBCacheStoreTest.tearDown > exception: > {code} > java.nio.channels.OverlappingFileLockException > at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) > at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152) > at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1017) > at java.nio.channels.FileChannel.tryLock(FileChannel.java:1154) > at org.iq80.leveldb.impl.DbLock.<init>(DbLock.java:47) > at org.iq80.leveldb.impl.DbImpl.<init>(DbImpl.java:167) > at org.iq80.leveldb.impl.Iq80DBFactory.open(Iq80DBFactory.java:59) > at org.infinispan.loaders.leveldb.LevelDBCacheStore.openDatabase(LevelDBCacheStore.java:83) > at org.infinispan.loaders.leveldb.LevelDBCacheStore.reinitDatabase(LevelDBCacheStore.java:95) > at org.infinispan.loaders.leveldb.LevelDBCacheStore.reinitAllDatabases(LevelDBCacheStore.java:99) > at org.infinispan.loaders.leveldb.LevelDBCacheStore.clearLockSafe(LevelDBCacheStore.java:152) > at org.infinispan.loaders.LockSupportCacheStore.clear(LockSupportCacheStore.java:270) > at org.infinispan.loaders.BaseCacheStoreTest.tearDown(BaseCacheStoreTest.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:796) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > {code} > run: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7313) AbstractFileLookup.lookupFileStrict broken on Windows

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-7313?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-7313. ----------------------------------- Fix Version/s: 9.1.8.Final 9.2.1.Final Resolution: Done > AbstractFileLookup.lookupFileStrict broken on Windows > ----------------------------------------------------- > > Key: ISPN-7313 > URL: https://issues.jboss.org/browse/ISPN-7313 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.5.Final, 9.0.0.Alpha4, 9.0.0.Beta1 > Environment: Using Infinispan as JCache provider in Spring Boot (v1.3.5) application on Windows (either IDE (Eclipse) or fat jar). > Reporter: Valued Customer > Priority: Major > Fix For: 9.1.8.Final, 9.2.1.Final > > > The fix in ISPN-5949 breaks Windows compatibility. > infinispan.xml is configured in application.properties > {noformat} > spring.cache.jcache.config=classpath:spring/infinispan.xml > {noformat} > When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown: > {noformat} > Caused by: org.infinispan.commons.CacheConfigurationException: > com.ctc.wstx.exc.WstxIOException: Stream closed > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119) > at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100) > at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56) > at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46) > at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67) > at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101) > ... > {noformat} > When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this: > * fat jar > {noformat} > jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml > {noformat} > * running app from within IDE > {noformat} > file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml > {noformat} > The problem ist now twofold: > # First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}. > {code} > public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException { > //in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas > int startIndex = uri.toString().lastIndexOf(':'); > String fileName = uri.toString().substring(startIndex + 1); > return cl.getResourceAsStream(fileName); > } > {code} > # This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}. > In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above. > The old code of {{lookupFileStrict()}} > {code} > return new FileInputStream(new File(uri)); > {code} > works fine from within the IDE, but is broken for a fat jar (ISPN-5949). > I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8198) RocksDB should not call System.gc() on non-windows systems

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8198?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8198: ---------------------------------- Status: Open (was: New) > RocksDB should not call System.gc() on non-windows systems > ---------------------------------------------------------- > > Key: ISPN-8198 > URL: https://issues.jboss.org/browse/ISPN-8198 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.CR3 > > > https://github.com/infinispan/infinispan/blob/f9b69a95a610b7bd3a8c31b509b... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8198) RocksDB should not call System.gc() on non-windows systems

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8198?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8198: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7394 > RocksDB should not call System.gc() on non-windows systems > ---------------------------------------------------------- > > Key: ISPN-8198 > URL: https://issues.jboss.org/browse/ISPN-8198 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.CR3 > > > https://github.com/infinispan/infinispan/blob/f9b69a95a610b7bd3a8c31b509b... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 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 2019