July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5581) "scala.MatchError: None" in HotRodEncoder

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5581?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5581: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1228676|https://bugzilla.redhat.com/show_bug.cgi?id=1228676] from NEW to ASSIGNED > "scala.MatchError: None" in HotRodEncoder > ----------------------------------------- > > Key: ISPN-5581 > URL: https://issues.jboss.org/browse/ISPN-5581 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 8.0.0.Alpha2, 7.2.3.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.2.4.Final, 8.0.0.Final > > > As a result of fixing ISPN-5576, the following exceptions have started appearing > {code} > [08:29:12] : [org.infinispan:infinispan-server-hotrod] 04:29:12,353 ERROR (HotRodServerWorker-11-1:) [HotRodEncoder] ISPN005023: Exception encoding message None > [08:29:12] : [org.infinispan:infinispan-server-hotrod] scala.MatchError: None (of class scala.None$) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:32) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:633) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:691) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:681) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:716) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:243) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.writeResponse(HotRodDecoder.scala:234) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:193) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeHeader(HotRodDecoder.scala:84) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:47) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:206) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:205) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.security.Security.doAs(Security.java:143) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:205) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) > [08:29:12] : [org.infinispan:infinispan-server-hotrod] at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5607: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1244133|https://bugzilla.redhat.com/show_bug.cgi?id=1244133] from NEW to ASSIGNED > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 7.2.4.Final, 8.0.0.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5616) Document the `metadata_writes_async` property of the Lucene Directory Provider

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5616?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-5616: ---------------------------------- Status: Open (was: New) > Document the `metadata_writes_async` property of the Lucene Directory Provider > ------------------------------------------------------------------------------ > > Key: ISPN-5616 > URL: https://issues.jboss.org/browse/ISPN-5616 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Reporter: Sanne Grinovero > > Moving responsibility to Infinispan documentation from > https://hibernate.atlassian.net/browse/HSEARCH-1729 > See also ISPN-5615 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5616) Document the `metadata_writes_async` property of the Lucene Directory Provider

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-5616: ------------------------------------- Summary: Document the `metadata_writes_async` property of the Lucene Directory Provider Key: ISPN-5616 URL: https://issues.jboss.org/browse/ISPN-5616 Project: Infinispan Issue Type: Task Components: Documentation-Query Reporter: Sanne Grinovero Moving responsibility to Infinispan documentation from https://hibernate.atlassian.net/browse/HSEARCH-1729 See also ISPN-5615 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5615) Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-5615: ------------------------------------- Summary: Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider Key: ISPN-5615 URL: https://issues.jboss.org/browse/ISPN-5615 Project: Infinispan Issue Type: Task Components: Documentation-Query Reporter: Sanne Grinovero Fix For: 8.0.0.Beta2 The general introduction to Infinispan should stay in the Hibernate Search documentation - http://docs.jboss.org/hibernate/search/5.3/reference/en-US/html_single/#i... But configuration options and tuning recommendations whould be transferred to the Infinispan reference documentation as the exact properties and their effect would depend on the Infinispan version being used (most of section 3.3.1.3. Infinispan Configuration) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5615) Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5615?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-5615: ---------------------------------- Status: Open (was: New) > Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5615 > URL: https://issues.jboss.org/browse/ISPN-5615 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Reporter: Sanne Grinovero > Fix For: 8.0.0.Beta2 > > > The general introduction to Infinispan should stay in the Hibernate Search documentation > - http://docs.jboss.org/hibernate/search/5.3/reference/en-US/html_single/#i... > But configuration options and tuning recommendations whould be transferred to the Infinispan reference documentation as the exact properties and their effect would depend on the Infinispan version being used (most of section 3.3.1.3. Infinispan Configuration) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5611) Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5611?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5611: ------------------------------------ Fix Version/s: 8.0.0.Beta2 (was: 8.0.0.CR1) > Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client > -------------------------------------------------------------------------------------- > > Key: ISPN-5611 > URL: https://issues.jboss.org/browse/ISPN-5611 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 8.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Beta2 > > > Currently the initial server that will hold the iteration state is automatically chosen based on segment ownership. If data location is known beforehand, it's more efficient to hint the iteration to start on a certain node. > The {{FailoverRequestBalancingStrategy}} is a mechanism in place to do that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5607: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1244133 > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 7.2.4.Final, 8.0.0.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5416) Grouping and aggregations with DSL based queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5416?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5416: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3591 > Grouping and aggregations with DSL based queries > ------------------------------------------------ > > Key: ISPN-5416 > URL: https://issues.jboss.org/browse/ISPN-5416 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > > Implement the 'group by' statement and the aggregate functions: count, sum, average, min, max. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned ISPN-5568: ---------------------------------------- Assignee: Bartosz Baranowski > 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 > > 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.3.15#6346)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015