March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6396) Improve the query indexing algorithm for continuous query

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6396?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6396: -------------------------------- Status: Open (was: New) > Improve the query indexing algorithm for continuous query > --------------------------------------------------------- > > Key: ISPN-6396 > URL: https://issues.jboss.org/browse/ISPN-6396 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Final > > > The current algorithm is ok in principle but it could use a bit of fine tuning in terms of the internal data structures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6093) When infinispan-remote and infinispan-embedded are deployed together we get an error

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6093?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6093: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha1 Resolution: Done > When infinispan-remote and infinispan-embedded are deployed together we get an error > ------------------------------------------------------------------------------------ > > Key: ISPN-6093 > URL: https://issues.jboss.org/browse/ISPN-6093 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final, 8.2.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 9.0.0.Alpha1, 8.1.3.Final, 8.2.1.Final > > > {code} > Exception in thread "main" java.lang.NoSuchMethodError: org.infinispan.commons.logging.BasicLogFactory.getLog(Ljava/lang/Class;)Lorg/jboss/logging/BasicLogger; > at org.infinispan.client.hotrod.impl.operations.PingOperation.<clinit>(PingOperation.java:25) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.ping(TransportObjectFactory.java:51) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:45) > at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16) > at infinispan.org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.pingServersIgnoreException(TcpTransportFactory.java:177) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.start(TcpTransportFactory.java:148) > at org.infinispan.client.hotrod.RemoteCacheManager.start(RemoteCacheManager.java:579) > at org.infinispan.client.hotrod.RemoteCacheManager.<init>(RemoteCacheManager.java:380) > at org.infinispan.client.hotrod.RemoteCacheManager.<init>(RemoteCacheManager.java:387) > at org.infinispan.data.RemoteWordCount.main(RemoteWordCount.java:25) > 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) > {code} > The main cause is that in embedded BasicLogger is relocated whereas in remote it's not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6390) Transport initial cluster timeout resets whenever a new node joins

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6390?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6390: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4138 > Transport initial cluster timeout resets whenever a new node joins > ------------------------------------------------------------------ > > Key: ISPN-6390 > URL: https://issues.jboss.org/browse/ISPN-6390 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 8.2.1.Final > > > {{JGroupsTransport.waitForInitialNodes()}} calls {{waitForView(currentViewId + 1, timeout, MILLISECONDS)}} repeatedly, and doesn't adjust the timeout when a new view is installed. > This means a node joining/leaving just before the timeout expire will effectively double the timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6239) InitialClusterSizeTest.testInitialClusterSizeFail random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6239?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6239: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/4030, https://github.com/infinispan/infinispan/pull/4138 (was: https://github.com/infinispan/infinispan/pull/4030) > InitialClusterSizeTest.testInitialClusterSizeFail random failures > ----------------------------------------------------------------- > > Key: ISPN-6239 > URL: https://issues.jboss.org/browse/ISPN-6239 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_failure > Fix For: 8.2.0.CR1, 8.2.0.Final > > > The test starts 3 nodes concurrently, but configures Infinispan to wait for a cluster of 4 nodes, and expects that the nodes fail to start in {{initialClusterTimeout}} + 1 second. > However, because of a bug in {{TEST_PING}}, the first 2 nodes see each other as coordinator and send a {{JOIN}} request to each other, and it takes 3 seconds to recover and start the cluster properly. > The bug in {{TEST_PING}} is actually a hack introduced for {{ISPN-5106}}. The problem was that the first node (A) to start would install a view with itself as the single node, but the second node to start (B) would start immediately, and the discovery request from B would reach B's {{TEST_PING}} before it saw the view. That way, B could choose itself as the coordinator based on the order of A's and B's UUIDs, and the cluster would start as 2 partitions. Since most of our tests actually remove {{MERGE3}} from the protocol stack, the partitions would never merge and the test would fail with a timeout. > I fixed this in {{TEST_PING}} by assuming that the sender of the first discovery response is a coordinator, when there is a single response. This worked because all but a few tests start their managers sequentially, however it sometimes introduces this 3 seconds delay when nodes start in parallel. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6391) Cache managers failing to start do not stop global components

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6391?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6391: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4138 > Cache managers failing to start do not stop global components > ------------------------------------------------------------- > > Key: ISPN-6391 > URL: https://issues.jboss.org/browse/ISPN-6391 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final, 8.2.1.Final > > > If one of the global components fails to start, {{GlobalComponentRegistry.start()}} removes the volatile components, but it doesn't call {{stop()}} on those components. > The most likely reason for a global component start failure is a timeout in {{JGroupsTransport.waitForInitialNodes()}}. After such a timeout, the transport isn't stopped, so the channel's sockets and threads are only freed after a few GC cycles (via finalization). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6349) Add primitive CacheStream interfaces

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6349?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6349: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add primitive CacheStream interfaces > ------------------------------------ > > Key: ISPN-6349 > URL: https://issues.jboss.org/browse/ISPN-6349 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha1 > > > With ISPN-6272 we now have full CacheStream support for returns on operator invocations. e should also do this for the primitive interfaces (DoubleStream/IntStream/LongStream). The thought is to call them CacheDoubleStream/CacheIntStream/CacheLongStream. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6113) Implement CH persistence to Global State

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6113?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6113: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > Implement CH persistence to Global State > ---------------------------------------- > > Key: ISPN-6113 > URL: https://issues.jboss.org/browse/ISPN-6113 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.Final > > > Consistent Hashes should be persistable and restorable to preserve any information related to segment ownership. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6113) Implement CH persistence to Global State

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6113?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6113: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3960 > Implement CH persistence to Global State > ---------------------------------------- > > Key: ISPN-6113 > URL: https://issues.jboss.org/browse/ISPN-6113 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.Final > > > Consistent Hashes should be persistable and restorable to preserve any information related to segment ownership. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3351) Controlled cluster shutdown with data restore from persistent storage

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3351?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3351: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4141 > Controlled cluster shutdown with data restore from persistent storage > --------------------------------------------------------------------- > > Key: ISPN-3351 > URL: https://issues.jboss.org/browse/ISPN-3351 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Loaders and Stores > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Labels: roadmap > > https://github.com/infinispan/infinispan/wiki/Graceful-shutdown-&-restore > https://community.jboss.org/wiki/ControlledClusterShutdownWithDataRestore... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6348) Full-text features for remote query

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6348?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-6348: ----------------------------------- Assignee: Adrian Nistor > Full-text features for remote query > ------------------------------------ > > Key: ISPN-6348 > URL: https://issues.jboss.org/browse/ISPN-6348 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Final > > > * we need a way to configure analysers for fields > * keyword and fuzzy querying wanted -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 March 2016