September 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5684) ISPN000136 concurrent TimeoutException if a HotRod client uses getAll(...) and the owners < numOfNodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5684?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5684: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1259433|https://bugzilla.redhat.com/show_bug.cgi?id=1259433] from ON_QA to VERIFIED > ISPN000136 concurrent TimeoutException if a HotRod client uses getAll(...) and the owners < numOfNodes > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-5684 > URL: https://issues.jboss.org/browse/ISPN-5684 > Project: Infinispan > Issue Type: Bug > Components: Core > Environment: Current upstream: > 615b91b (HEAD, upstream/master, master) ISPN-5595 Deployed Cache Store Factory operates on promises > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 8.0.0.Final > > Attachments: TestGetAll.java, TestGetAll2.java > > > If a distributed cache configuration contains less owner than current nodes are within the cluster a HotRod client fail if the copatible mode is enabled. > The getAll(...) must include keys of different owners to fail constant. > The ERROR is as followed: > 19:04:08,991 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-9-1) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 3 > at org.infinispan.statetransfer.StateTransferLockImpl.waitForTopology(StateTransferLockImpl.java:144) > at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTopology(BaseStateTransferInterceptor.java:100) > at org.infinispan.statetransfer.StateTransferInterceptor.visitGetAllCommand(StateTransferInterceptor.java:177) > at org.infinispan.commands.read.GetAllCommand.acceptVisitor(GetAllCommand.java:59) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetAllCommand(CacheMgmtInterceptor.java:127) > at org.infinispan.commands.read.GetAllCommand.acceptVisitor(GetAllCommand.java:59) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitGetAllCommand(BaseTypeConverterInterceptor.java:166) > at org.infinispan.commands.read.GetAllCommand.acceptVisitor(GetAllCommand.java:59) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > at org.infinispan.commands.AbstractVisitor.visitGetAllCommand(AbstractVisitor.java:95) > at org.infinispan.commands.read.GetAllCommand.acceptVisitor(GetAllCommand.java:59) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitGetAllCommand(AbstractVisitor.java:95) > at org.infinispan.commands.read.GetAllCommand.acceptVisitor(GetAllCommand.java:59) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > at org.infinispan.cache.impl.CacheImpl.getAll(CacheImpl.java:443) > at org.infinispan.cache.impl.DecoratedCache.getAll(DecoratedCache.java:442) > at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.getAll(AbstractDelegatingAdvancedCache.java:207) > at org.infinispan.server.hotrod.Decoder2x$.customReadValue(Decoder2x.scala:482) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeValue(HotRodDecoder.scala:197) > at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeValue(HotRodDecoder.scala:136) > at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:50) > at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:206) > at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45) > at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370) > at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168) > at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31) > at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32) > at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) > at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) > at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) > at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5737) Cannot use both 'where' and 'having' filtering in the same query

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5737?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5737: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1261563|https://bugzilla.redhat.com/show_bug.cgi?id=1261563] from ON_QA to VERIFIED > Cannot use both 'where' and 'having' filtering in the same query > ---------------------------------------------------------------- > > Key: ISPN-5737 > URL: https://issues.jboss.org/browse/ISPN-5737 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Jakub Markos > Assignee: Adrian Nistor > Fix For: 8.0.1.Final > > > This query > {code} > Query q = qf.from(getModelFactory().getUserImplClass()) > .select("name") > .having("name").eq("John").toBuilder() > .groupBy("name") > .having("name").eq("John").toBuilder() > .build(); > {code} > fails with > {code} > java.lang.IllegalStateException: Sentence already started. Cannot use 'having(..)' again. > at org.infinispan.query.dsl.impl.BaseQueryBuilder.having(BaseQueryBuilder.java:178) > at org.infinispan.query.dsl.impl.BaseQueryBuilder.having(BaseQueryBuilder.java:188) > at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testCustomQueryBuilding(QueryDslConditionsTest.java:2180) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > 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:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5732) Aggregation functions should ignore NULL values

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5732?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5732: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1261563|https://bugzilla.redhat.com/show_bug.cgi?id=1261563] from ON_QA to VERIFIED > Aggregation functions should ignore NULL values > ----------------------------------------------- > > Key: ISPN-5732 > URL: https://issues.jboss.org/browse/ISPN-5732 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Jakub Markos > Assignee: Adrian Nistor > Fix For: 8.0.1.Final > > > For example, this query returns 3 (in QueryDslConditionsTest) > {code} > public void testCountNull() { > QueryFactory qf = getQueryFactory(); > Query q = qf.from(getModelFactory().getUserImplClass()) > .select(Expression.count("age")) > .build(); > {code} > while only 1 value is non-null. > It might be good to behave like JPA, which ignores NULL values: > "Null values are eliminated before the aggregate function is applied, regardless of whether the keyword DISTINCT is specified." http://download.oracle.com/otn-pub/jcp/persistence-2.0-fr-eval-oth-JSpec/... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5731) Cannot use aggregation expression in orderBy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5731?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5731: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1261563|https://bugzilla.redhat.com/show_bug.cgi?id=1261563] from ON_QA to VERIFIED > Cannot use aggregation expression in orderBy > -------------------------------------------- > > Key: ISPN-5731 > URL: https://issues.jboss.org/browse/ISPN-5731 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Jakub Markos > Assignee: Adrian Nistor > Fix For: 8.0.1.Final > > > The following query > {code} > public void testSumOrderBy() { > QueryFactory qf = getQueryFactory(); > Query q = qf.from(getModelFactory().getUserImplClass()) > .select(Expression.sum("age")) > .orderBy(Expression.sum("age")) > .build(); > } > {code} > in the context of QueryDslConditionsTest test class fails with > {code} > org.antlr.runtime.tree.RewriteEmptyStreamException: rule propertyReferencePath > at org.antlr.runtime.tree.RewriteRuleElementStream._next(RewriteRuleElementStream.java:157) > at org.antlr.runtime.tree.RewriteRuleElementStream.nextTree(RewriteRuleElementStream.java:144) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.valueExpressionPrimary(GeneratedHQLResolver.java:8036) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.valueExpression(GeneratedHQLResolver.java:7538) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.sortSpecification(GeneratedHQLResolver.java:4563) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.orderByClause(GeneratedHQLResolver.java:4469) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatement(GeneratedHQLResolver.java:1766) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.queryStatementSet(GeneratedHQLResolver.java:1658) > at org.hibernate.hql.ast.origin.hql.resolve.GeneratedHQLResolver.statement(GeneratedHQLResolver.java:654) > at org.hibernate.hql.ast.spi.QueryResolverProcessor.process(QueryResolverProcessor.java:52) > at org.hibernate.hql.QueryParser.parseQuery(QueryParser.java:82) > at org.infinispan.objectfilter.impl.BaseMatcher.parse(BaseMatcher.java:125) > at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:398) > at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:86) > at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:38) > at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:45) > at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testSumOrderBy(QueryDslConditionsTest.java:1976) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > 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:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4046) New query dsl does not support isNull filters for non-string properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4046?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4046: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1261665|https://bugzilla.redhat.com/show_bug.cgi?id=1261665] from ON_QA to VERIFIED > New query dsl does not support isNull filters for non-string properties > ----------------------------------------------------------------------- > > Key: ISPN-4046 > URL: https://issues.jboss.org/browse/ISPN-4046 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.1.Final, 7.2.5.Final > > > String properties can be supported because of Hibernate Search null token, but HSearch only offers this for strings and not for other types. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5717) Continuous query ignores expired entries

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5717: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1258982|https://bugzilla.redhat.com/show_bug.cgi?id=1258982] from ON_QA to VERIFIED > Continuous query ignores expired entries > ---------------------------------------- > > Key: ISPN-5717 > URL: https://issues.jboss.org/browse/ISPN-5717 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 8.0.1.Final > > > When cache entry expires, CQ listeners are not updated and thus can server obsolete results -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5713) Extend Continuous Query test coverage

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5713?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5713: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1258982|https://bugzilla.redhat.com/show_bug.cgi?id=1258982] from ON_QA to VERIFIED > Extend Continuous Query test coverage > ------------------------------------- > > Key: ISPN-5713 > URL: https://issues.jboss.org/browse/ISPN-5713 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 8.0.1.Final > > > Implement test which > * verifies that notification is sent also for expired entries > * updates work correctly also for more complex queries which combines several predicates > * updates work correctly when node a started/shut down -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5724) Expiration and Continuous packages are missing API docs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5724?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5724: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1259344|https://bugzilla.redhat.com/show_bug.cgi?id=1259344] from ON_QA to VERIFIED > Expiration and Continuous packages are missing API docs > ------------------------------------------------------- > > Key: ISPN-5724 > URL: https://issues.jboss.org/browse/ISPN-5724 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 8.0.0.Final > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Priority: Minor > Fix For: 8.0.1.Final > > > Following packages were recently added, but are missing in javadoc (and IMHO these should be covered there): > org.infinispan.expiration > org.infinispan.query.continuous -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5568) KeyAffinityService race condition on view change

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5568: ----------------------------------------------- Ivan Straka <istraka(a)redhat.com> changed the Status of [bug 1233968|https://bugzilla.redhat.com/show_bug.cgi?id=1233968] from ON_QA to VERIFIED > KeyAffinityService race condition on view change > ------------------------------------------------ > > Key: ISPN-5568 > URL: https://issues.jboss.org/browse/ISPN-5568 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.11.Final > Reporter: Dennis Reed > Assignee: Bartosz Baranowski > Fix For: 8.0.0.Beta2, 5.2.14.Final, 7.2.4.Final > > > KeyAffinityService#getKeyForAddress runs in a tight loop looking for keys: > {noformat} > queue = address2key.get(address) > while (result == null) > result = queue.poll() > {noformat} > KeyAffinityService#handleViewChange clears and resets the queue list on membership change: > {noformat} > address2key.clear() > for each address > map.put(address, new queue) > {noformat} > If a view change comes in after getKeyForAddress gets the queue, and the queue is empty, it will get stuck in a tight loop looking at the wrong queue forever while new keys are added to the new queue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5526: ----------------------------------------------- Ivan Straka <istraka(a)redhat.com> changed the Status of [bug 1228780|https://bugzilla.redhat.com/show_bug.cgi?id=1228780] from ON_QA to VERIFIED > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Ryan Emerson > Priority: Critical > Fix For: 5.2.13.Final > > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2015