April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5369) SuspectException can be thrown without the target node leaving the JGroups view

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5369?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5369: ------------------------------- Status: Open (was: New) > SuspectException can be thrown without the target node leaving the JGroups view > ------------------------------------------------------------------------------- > > Key: ISPN-5369 > URL: https://issues.jboss.org/browse/ISPN-5369 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.CR1 > > > When we retry RPCs on a SuspectException, we wait for a new cache topology before resending the RPC. Without the delay, the sender would entera very tight loop of invoking the RPC and immediately receiving a SuspectException. > But in certain edge cases, it's possible to receive a SuspectException without the suspected node ever being eliminated from the JGroups view (and without installing a new cache topology). That means the thread waiting to retry the RPC will block forever. > The problem is that RequestCorrelator listens to SUSPECT events directly. If the FD protocol then raises an UNSUSPECT event, GMS will not install a new view. > The solution should be to ignore SUSPECT events in RequestCorrelator, and only act on view changes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5369) SuspectException can be thrown without the target node leaving the JGroups view

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5369?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5369: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3369 > SuspectException can be thrown without the target node leaving the JGroups view > ------------------------------------------------------------------------------- > > Key: ISPN-5369 > URL: https://issues.jboss.org/browse/ISPN-5369 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.CR1 > > > When we retry RPCs on a SuspectException, we wait for a new cache topology before resending the RPC. Without the delay, the sender would entera very tight loop of invoking the RPC and immediately receiving a SuspectException. > But in certain edge cases, it's possible to receive a SuspectException without the suspected node ever being eliminated from the JGroups view (and without installing a new cache topology). That means the thread waiting to retry the RPC will block forever. > The problem is that RequestCorrelator listens to SUSPECT events directly. If the FD protocol then raises an UNSUSPECT event, GMS will not install a new view. > The solution should be to ignore SUSPECT events in RequestCorrelator, and only act on view changes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5369) SuspectException can be thrown without the target node leaving the JGroups view

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5369: ---------------------------------- Summary: SuspectException can be thrown without the target node leaving the JGroups view Key: ISPN-5369 URL: https://issues.jboss.org/browse/ISPN-5369 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.1.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.2.0.CR1 When we retry RPCs on a SuspectException, we wait for a new cache topology before resending the RPC. Without the delay, the sender would entera very tight loop of invoking the RPC and immediately receiving a SuspectException. But in certain edge cases, it's possible to receive a SuspectException without the suspected node ever being eliminated from the JGroups view (and without installing a new cache topology). That means the thread waiting to retry the RPC will block forever. The problem is that RequestCorrelator listens to SUSPECT events directly. If the FD protocol then raises an UNSUSPECT event, GMS will not install a new view. The solution should be to ignore SUSPECT events in RequestCorrelator, and only act on view changes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-951) Infinispan Query module should load entities using getAll

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-951?page=com.atlassian.jira.plugin.s... ] Sanne Grinovero commented on ISPN-951: -------------------------------------- The method {{getAll}} is now available in Infinispan, we could now finally use that. (Adjusted the issue title) > Infinispan Query module should load entities using getAll > --------------------------------------------------------- > > Key: ISPN-951 > URL: https://issues.jboss.org/browse/ISPN-951 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > > Ideally we should use a method like {{List getAll(Object[] keys)}} from Infinispan core, but that doesn't exist yet. Such a method would be able to split the keys in such a way to minimize the number of RPCs needed to "cover" the set of all segments needed to satisfy the query, so to find the minimum set of nodes available which need to be contacted to retrieve all entries. > Loading of each entry doesn't necessarily need to happen sequentially, I guess the minimum set of RPCs should be executed in parallel, then we block until they are all returned and need to restore the order of the list (the order of the return elements need to match the order of their respective keys from the parameter). > We should implement such a method, or until that's possible it might be easier to run each individual get in a {{getAsync}} so that the latency of a Query returning for example 100 entries doesn't scale up to 100 sequential RPCs. > Requires migration to new Loader API from Hibernate Search. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-951) Infinispan Query module should load entities using getAll

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-951?page=com.atlassian.jira.plugin.s... ] Sanne Grinovero updated ISPN-951: --------------------------------- Summary: Infinispan Query module should load entities using getAll (was: Infinispan Query module should load entities using getAsync) > Infinispan Query module should load entities using getAll > --------------------------------------------------------- > > Key: ISPN-951 > URL: https://issues.jboss.org/browse/ISPN-951 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > > Ideally we should use a method like {{List getAll(Object[] keys)}} from Infinispan core, but that doesn't exist yet. Such a method would be able to split the keys in such a way to minimize the number of RPCs needed to "cover" the set of all segments needed to satisfy the query, so to find the minimum set of nodes available which need to be contacted to retrieve all entries. > Loading of each entry doesn't necessarily need to happen sequentially, I guess the minimum set of RPCs should be executed in parallel, then we block until they are all returned and need to restore the order of the list (the order of the return elements need to match the order of their respective keys from the parameter). > We should implement such a method, or until that's possible it might be easier to run each individual get in a {{getAsync}} so that the latency of a Query returning for example 100 entries doesn't scale up to 100 sequential RPCs. > Requires migration to new Loader API from Hibernate Search. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5368: --------------------------------------- Summary: Out of order events produced when using the MassIndexer with async backend Key: ISPN-5368 URL: https://issues.jboss.org/browse/ISPN-5368 Project: Infinispan Issue Type: Bug Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes When using async indexing backend on DIST caches with shared index (InfinispanIndexManager), the MassIndexer fails intermittently to re-index all the entries. Normally the operation sequence of the MassIndexer in the above configuration, for a two node cluster is: * Purge the index * Send index job to node A and to node B * Flush Given the backend is async, all commands are sent RPC-wise asynchronously, and so a reorder can occur and produce like: * Send index job to node A * Purge * Send index job to node B * Flush Causing previously re-indexed entries to be wiped -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5365) JmxManagementIT.testCacheStatisticsAttributes always fails

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-5365?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-5365: ------------------------------------------- I messed this one up. Will resolve it asap. > JmxManagementIT.testCacheStatisticsAttributes always fails > ----------------------------------------------------------- > > Key: ISPN-5365 > URL: https://issues.jboss.org/browse/ISPN-5365 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.2.0.CR1 > > > Looks like the {{ElapsedTime}} attribute got renamed to {{TimeSinceStart}}, and {{JmxManagementIT}} still uses the old name: > {noformat} > javax.management.AttributeNotFoundException: Unknown attribute 'ElapsedTime'. Known attributes names are: [numberOfEntries, averageReadTime, hitRatio, timeSinceReset, averageRemoveTime, misses, evictions, readWriteRatio, statisticsEnabled, hits, timeSinceStart, removeMisses, removeHits, stores, averageWriteTime] > at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:181) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.getAttribute(PluggableMBeanServerImpl.java:1377) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:384) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:415) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > 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:745) > {noformat} > I think maybe we should keep the old attribute name as well, for backwards compatibility. I'm thinking RHQ might use it... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5264) Optimize PutAll operations (library mode)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5264?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5264: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Optimize PutAll operations (library mode) > ----------------------------------------- > > Key: ISPN-5264 > URL: https://issues.jboss.org/browse/ISPN-5264 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.CR1, 7.2.0.Final > > > - PutAll: to ensure that users can load massive amount of data into the grid quickly in Library mode > - Performance improvement over large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5367) Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation

by William Burns (JIRA)

William Burns created ISPN-5367: ----------------------------------- Summary: Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation Key: ISPN-5367 URL: https://issues.jboss.org/browse/ISPN-5367 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: William Burns Assignee: William Burns Fix For: 7.2.0.CR1 With the putAll method I introduced a SegmentAwareMap and SegmentAwareSet in thoughts that not copying all the elements would help performance. Thinking more it may be better to just make a new shallow copy map for each target instead. Need to do some testing to make sure if one is clearly better than the other. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5147) Creation/configuration of caches should not require a server restart

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5147?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5147: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3368 > Creation/configuration of caches should not require a server restart > -------------------------------------------------------------------- > > Key: ISPN-5147 > URL: https://issues.jboss.org/browse/ISPN-5147 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > When creating a cache using the management interface, we want to be able to set all specific configuration and start the cache without requiring a server restart. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015