October 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6721) SuspectException when stopping and starting nodes in an embedded cluster using invalidation

by Gunther v. Wolffersdorff (JIRA)

[ https://issues.jboss.org/browse/ISPN-6721?page=com.atlassian.jira.plugin.... ] Gunther v. Wolffersdorff updated ISPN-6721: ------------------------------------------- Attachment: server.log > SuspectException when stopping and starting nodes in an embedded cluster using invalidation > ------------------------------------------------------------------------------------------- > > Key: ISPN-6721 > URL: https://issues.jboss.org/browse/ISPN-6721 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.2.Final > Reporter: Karl von Randow > Attachments: server.log, SyncInvalidationLeaveTest.java > > > We run a cluster of four app servers on Tomcat with embedded Infinispan for Hibernate L2. When we bring down one of the app servers it shuts down that cache and then exits. On other nodes we frequently, although not consistently, receive SuspectExceptions from other nodes stating that the cache isn't running on the shutting down node. Similarly when starting a new app server we get the same. > We are using synchronous invalidation. > This feels like a race condition during startup and shutdown of the caches. Does that sound likely? > I note in this wiki article https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-I... there is a note "TODO Create an issue in JIRA to ignore suspect exceptions.". I'm not sure if this is related! > There are two stacktraces below. I note that the shutdown example fails in {{JGroupsTransport.java:798}} which is when the response was suspected. While the startup example fails in {{JGroupsTransport.java:795}}, which is a {{CacheNotFoundResponse}} response. > Here is a shutdown exception: > {code:java} > May 27, 2016 3:05:01 PM org.apache.catalina.core.StandardWrapperValve invoke > SEVERE: Servlet.service() for servlet [default] in context with path [] threw exception > org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-12786 > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:798) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:162) > at org.jgroups.blocks.GroupRequest.viewChange(GroupRequest.java:250) > at org.jgroups.blocks.RequestCorrelator.receiveView(RequestCorrelator.java:316) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:229) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:392) > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:733) > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:140) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:923) > at org.jgroups.stack.Protocol.up(Protocol.java:417) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474) > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982) > at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912) > at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1590) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802) > 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} > And a startup exception: > {code:java} > org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node app1-46933 > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:162) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:136) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:373) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:237) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:392) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1590) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802) > 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 (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7153) Add documentation regarding memory based eviction

by William Burns (JIRA)

William Burns created ISPN-7153: ----------------------------------- Summary: Add documentation regarding memory based eviction Key: ISPN-7153 URL: https://issues.jboss.org/browse/ISPN-7153 Project: Infinispan Issue Type: Task Components: Documentation-Core Reporter: William Burns Assignee: William Burns Blog post already at http://blog.infinispan.org/2015/09/memory-based-eviction.html -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7152) Query DSL like operator should consider \ as escape character

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-7152: ----------------------------------- Summary: Query DSL like operator should consider \ as escape character Key: ISPN-7152 URL: https://issues.jboss.org/browse/ISPN-7152 Project: Infinispan Issue Type: Bug Components: Embedded Querying, Remote Querying Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 9.0.0.Beta1, 9.0.0.Final Users should be able to escape wildcards by placing an escape char in front of them. The default escape char is \. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6939) Replace the LevelDB cache store with one based on RocksDB

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6939?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-6939. -------------------------------- Resolution: Done > Replace the LevelDB cache store with one based on RocksDB > --------------------------------------------------------- > > Key: ISPN-6939 > URL: https://issues.jboss.org/browse/ISPN-6939 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Final > > > RocksDB is a forked LevelDB that provides better performance and support. The JNI layer is also maintained in sync with the native code. > The LevelDB implementation can be replaced with RocksDB while providing the same configuration API. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7142) Query DSL like operator should consider \ as escape character

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7142?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7142: -------------------------------- Fix Version/s: 9.0.0.Final > Query DSL like operator should consider \ as escape character > ------------------------------------------------------------- > > Key: ISPN-7142 > URL: https://issues.jboss.org/browse/ISPN-7142 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > Users should be able to escape wildcards by placing an escape char in front of them. The default escape char is \. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7151) Migrate to Typescript 2.0

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7151?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7151: ------------------------------- Priority: Minor (was: Major) > Migrate to Typescript 2.0 > ------------------------- > > Key: ISPN-7151 > URL: https://issues.jboss.org/browse/ISPN-7151 > Project: Infinispan > Issue Type: Task > Components: Console > Affects Versions: 9.0.0.Alpha4 > Reporter: Ryan Emerson > Priority: Minor > > We should migrate from Typescript 1.x to 2.x. As well as many new features, the key benefit of such a transition is that it removes the need to utilises Typings as the ability to search/install t.ds files is now part of Typescript itself. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7151) Migrate to Typescript 2.0

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-7151: ---------------------------------- Summary: Migrate to Typescript 2.0 Key: ISPN-7151 URL: https://issues.jboss.org/browse/ISPN-7151 Project: Infinispan Issue Type: Task Components: Console Affects Versions: 9.0.0.Alpha4 Reporter: Ryan Emerson We should migrate from Typescript 1.x to 2.x. As well as many new features, the key benefit of such a transition is that it removes the need to utilises Typings as the ability to search/install t.ds files is now part of Typescript itself. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7142) Query DSL like operator should consider \ as escape character

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7142?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7142: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Query DSL like operator should consider \ as escape character > ------------------------------------------------------------- > > Key: ISPN-7142 > URL: https://issues.jboss.org/browse/ISPN-7142 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Beta1 > > > Users should be able to escape wildcards by placing an escape char in front of them. The default escape char is \. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7080) NPE in CacheNotifierImpl by LIRS eviction listener

by ted won (JIRA)

[ https://issues.jboss.org/browse/ISPN-7080?page=com.atlassian.jira.plugin.... ] ted won reassigned ISPN-7080: ----------------------------- Assignee: (was: ted won) > NPE in CacheNotifierImpl by LIRS eviction listener > --------------------------------------------------- > > Key: ISPN-7080 > URL: https://issues.jboss.org/browse/ISPN-7080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Environment: * Infinispan branch: Upstream master > Reporter: ted won > Labels: core, eviction, lirs > > The LIRSEvictionFunctionalTest.testSimpleEvictionMaxEntries unit test method in core module fails and throws NPE in CacheNotifierImpl.notifyCacheEntriesEvicted method when trying to reinsert the first keys again. > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > It reproduces only with LIRS eviction strategy and eviction listener. > However, LRU and UNORDERED eviction strategies are working properly. > It makes impossible the use of eviction listeners with LIRS eviction strategy. > It's able to reproduce by: > - inserting 20 keys - values in a 10 sized cache ( keys from key-1 to key-20), > - and then reinsert the first 10 keys (key-1 to key-10) -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7080) NPE in CacheNotifierImpl by LIRS eviction listener

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7080?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7080: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4639 (was: https://github.com/infinispan/infinispan/pull/4600) > NPE in CacheNotifierImpl by LIRS eviction listener > --------------------------------------------------- > > Key: ISPN-7080 > URL: https://issues.jboss.org/browse/ISPN-7080 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Environment: * Infinispan branch: Upstream master > Reporter: ted won > Assignee: ted won > Labels: core, eviction, lirs > > The LIRSEvictionFunctionalTest.testSimpleEvictionMaxEntries unit test method in core module fails and throws NPE in CacheNotifierImpl.notifyCacheEntriesEvicted method when trying to reinsert the first keys again. > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > It reproduces only with LIRS eviction strategy and eviction listener. > However, LRU and UNORDERED eviction strategies are working properly. > It makes impossible the use of eviction listeners with LIRS eviction strategy. > It's able to reproduce by: > - inserting 20 keys - values in a 10 sized cache ( keys from key-1 to key-20), > - and then reinsert the first 10 keys (key-1 to key-10) -- This message was sent by Atlassian JIRA (v7.2.2#72004)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2016