February 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4047) Use the sort criteria provided by hql-parser (after fixing HQLPARSER-24)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4047?page=com.atlassian.jira.plugin.... ] Work on ISPN-4047 started by Adrian Nistor. > Use the sort criteria provided by hql-parser (after fixing HQLPARSER-24) > ------------------------------------------------------------------------ > > Key: ISPN-4047 > URL: https://issues.jboss.org/browse/ISPN-4047 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Currently we have separate handling of the sort criteria in Infinispan because the JPQL parser skips it. See https://hibernate.atlassian.net/browse/HQLPARSER-24. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3899) XAResourceRecovery implementation needed for transaction recovery in library mode

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-3899?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-3899: ------------------------------------ [~mircea.markus] from what I understood with my chat with [~pferraro], it's needed because that's how Jboss TM operates: <pferraro> effectively, you need to register Infinispan's XAResource with the JBoss TM's XAResourceRecoveryRegistry This registration for example happens automatically for XA datasources on server startup. > XAResourceRecovery implementation needed for transaction recovery in library mode > --------------------------------------------------------------------------------- > > Key: ISPN-3899 > URL: https://issues.jboss.org/browse/ISPN-3899 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Galder Zamarreño > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > According to [~pferraro], an implementation of XAResourceRecovery needs to be added to Infinispan and plugged into XAResourceRecoveryRegistry in order to get recovery of XA transactions working as expected. > This is already done in Server/AS/Wildfly in org.jboss.as.clustering.infinispan.subsystem.CacheService class. > A similar thing should happen when Infinispan is used in embedded/library mode. > [~isavin], since you are going to work on the transaction changes in 7.0, maybe you can take this on too? It'd be interesting to add a test to start with which shows that XA transaction recovery is not working as expected as a result of not having this. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3899) XAResourceRecovery implementation needed for transaction recovery in library mode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3899?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3899: ------------------------------------- [~pferraro] cam you please elaborate why the XAResourceRecovery implementation is needed? ATM the recovery process can obtain a handle to a XAResource through cache.getAdvancedCache().getXAResource(), shouldn't that be enough? > XAResourceRecovery implementation needed for transaction recovery in library mode > --------------------------------------------------------------------------------- > > Key: ISPN-3899 > URL: https://issues.jboss.org/browse/ISPN-3899 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Galder Zamarreño > Assignee: Ion Savin > Fix For: 7.0.0.Final > > > According to [~pferraro], an implementation of XAResourceRecovery needs to be added to Infinispan and plugged into XAResourceRecoveryRegistry in order to get recovery of XA transactions working as expected. > This is already done in Server/AS/Wildfly in org.jboss.as.clustering.infinispan.subsystem.CacheService class. > A similar thing should happen when Infinispan is used in embedded/library mode. > [~isavin], since you are going to work on the transaction changes in 7.0, maybe you can take this on too? It'd be interesting to add a test to start with which shows that XA transaction recovery is not working as expected as a result of not having this. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4053?page=com.atlassian.jira.plugin.... ] Work on ISPN-4053 started by Pedro Ruivo. > WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode > ----------------------------------------------------------------------- > > Key: ISPN-4053 > URL: https://issues.jboss.org/browse/ISPN-4053 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions. > Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4053: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1047908 > WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode > ----------------------------------------------------------------------- > > Key: ISPN-4053 > URL: https://issues.jboss.org/browse/ISPN-4053 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions. > Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-4053: --------------------------------- Summary: WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode Key: ISPN-4053 URL: https://issues.jboss.org/browse/ISPN-4053 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.1.Final Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 7.0.0.Alpha1, 7.0.0.Final The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions. Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4051) ProtoStream should provide guidelines when it fails to resolve dependencies correctly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4051?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4051: ---------------------------------- Summary: ProtoStream should provide guidelines when it fails to resolve dependencies correctly (was: ProtoStream fails to resolve dependencies correctly) > ProtoStream should provide guidelines when it fails to resolve dependencies correctly > ------------------------------------------------------------------------------------- > > Key: ISPN-4051 > URL: https://issues.jboss.org/browse/ISPN-4051 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > > Attempting to import a ProtoBuf definition which uses imports fails with: > Caused by: com.google.protobuf.Descriptors$DescriptorValidationException: AeiReaderMessage_M.proto: Dependencies passed to FileDescriptor.buildFrom() don't match those listed in the FileDescriptorProto. > at com.google.protobuf.Descriptors$FileDescriptor.buildFrom(Descriptors.java:240) > at org.infinispan.protostream.impl.SerializationContextImpl.registerProtofile(SerializationContextImpl.java:61) > at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.registerProtofile(ProtobufMetadataManager.java:154) > at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.modified(ProtobufMetadataManager.java:149) > This is caused by the fact that SerializationContextImpl#resolveDeps returns an empty array even though the inlcuded file is actually in the definition. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4051) ProtoStream fails to resolve dependencies correctly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4051?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4051: --------------------------------------- This was caused by the protoc compiler not being invoked with --include-imports. Maybe we should provide a better error message > ProtoStream fails to resolve dependencies correctly > --------------------------------------------------- > > Key: ISPN-4051 > URL: https://issues.jboss.org/browse/ISPN-4051 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > > Attempting to import a ProtoBuf definition which uses imports fails with: > Caused by: com.google.protobuf.Descriptors$DescriptorValidationException: AeiReaderMessage_M.proto: Dependencies passed to FileDescriptor.buildFrom() don't match those listed in the FileDescriptorProto. > at com.google.protobuf.Descriptors$FileDescriptor.buildFrom(Descriptors.java:240) > at org.infinispan.protostream.impl.SerializationContextImpl.registerProtofile(SerializationContextImpl.java:61) > at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.registerProtofile(ProtobufMetadataManager.java:154) > at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.modified(ProtobufMetadataManager.java:149) > This is caused by the fact that SerializationContextImpl#resolveDeps returns an empty array even though the inlcuded file is actually in the definition. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2780) org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2780?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2780: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 906317|https://bugzilla.redhat.com/show_bug.cgi?id=906317] from ASSIGNED to CLOSED > org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments > --------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2780 > URL: https://issues.jboss.org/browse/ISPN-2780 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.0.CR3 > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Priority: Critical > Labels: retest, stable_embedded_query, testsuite_stability > > The test org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails almost always on all environments. The error message is: > {code} > Error Message > String '0' should exist but was not found in index > Stacktrace > java.lang.AssertionError: String '0' should exist but was not found in index > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyOnDirectory(IndexCacheLoaderTest.java:131) > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyIndex(IndexCacheLoaderTest.java:83) > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest(IndexCacheLoaderTest.java:71) > 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:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > 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:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {code} -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4052) Quickstart distribution example does not work with xml configuration

by Anton Lisovenko (JIRA)

Anton Lisovenko created ISPN-4052: ------------------------------------- Summary: Quickstart distribution example does not work with xml configuration Key: ISPN-4052 URL: https://issues.jboss.org/browse/ISPN-4052 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.Final Reporter: Anton Lisovenko Assignee: Mircea Markus org.infinispan.quickstart.clusteredcache.distribution.AbstractNode has the block this.cacheManager = createCacheManagerProgramatically(); // Uncomment to create cache from XML /*try { this.cacheManager = createCacheManagerFromXml(); } catch (IOException e) { throw new RuntimeException(e); }*/ When I uncomment the xml configuration and run Node0, I recieve the error: {quote} Exception in thread "main" org.infinispan.commons.CacheConfigurationException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[29,4] Message: found: CHARACTERS, expected START_ELEMENT or END_ELEMENT at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:102) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:251) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:224) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:211) at org.infinispan.quickstart.clusteredcache.distribution.AbstractNode.createCacheManagerFromXml(AbstractNode.java:51) at org.infinispan.quickstart.clusteredcache.distribution.AbstractNode.<init>(AbstractNode.java:62) at org.infinispan.quickstart.clusteredcache.distribution.Node0.<init>(Node0.java:28) at org.infinispan.quickstart.clusteredcache.distribution.Node0.main(Node0.java:31) 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:601) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[29,4] Message: found: CHARACTERS, expected START_ELEMENT or END_ELEMENT at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.nextTag(XMLStreamReaderImpl.java:1250) at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.nextTag(XMLExtendedStreamReaderImpl.java:88) at org.infinispan.configuration.parsing.Parser60.readElement(Parser60.java:64) at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:141) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:123) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:110) at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:97) ... 12 more {quote} -- 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

12 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2014