December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-3743) Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3743?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3743: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1039090|https://bugzilla.redhat.com/show_bug.cgi?id=1039090] from NEW to ON_QA > Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions > -------------------------------------------------------------------------------- > > Key: ISPN-3743 > URL: https://issues.jboss.org/browse/ISPN-3743 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.Beta1 > > > When a cache in STOPPING state receives a command, the exception is propagated all the way to the caller: > {noformat} > 09:33:02,005 ERROR (testng-NonTxPutIfAbsentDuringLeaveStressTest:) [UnitTestTestNGListener] Test testNodeLeavingDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest) failed. > java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeD-57301, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) > Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:93) > {noformat} > This causes random failures in NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent. > The originator should either ignore the IllegalStateException or wait for a new cache topology and retry the operation, just like it should for SuspectExceptions (ISPN-2577). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3081) JBoss Modules logging produces garbage at the beginning of line

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3081?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3081: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1033821|https://bugzilla.redhat.com/show_bug.cgi?id=1033821] from NEW to CLOSED > JBoss Modules logging produces garbage at the beginning of line > --------------------------------------------------------------- > > Key: ISPN-3081 > URL: https://issues.jboss.org/browse/ISPN-3081 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Alpha1, 6.0.0.Final > Reporter: Michal Linhard > Attachments: configs.zip, serverlogs.zip > > > This is what I get on the console when running infinispan-server-5.3.0-SNAPSHOT > {code} > [0m06:38:12,718 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.CR1 > [0m[0m06:38:13,282 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA > [0m[0m06:38:13,486 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) starting > [0m[31m06:38:14,687 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > .. > {code} > configuration: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s... > whole logs: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4163) CacheAuthorizationTest.testAllCombinations always fails on JDK8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4163?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4163: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1173645|https://bugzilla.redhat.com/show_bug.cgi?id=1173645] from NEW to POST > CacheAuthorizationTest.testAllCombinations always fails on JDK8 > --------------------------------------------------------------- > > Key: ISPN-4163 > URL: https://issues.jboss.org/browse/ISPN-4163 > Project: Infinispan > Issue Type: Bug > Components: Security, Test Suite - Core > Affects Versions: 7.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Labels: testsuite_stability > Fix For: 7.0.0.Alpha5 > > > JDK8 added some new default methods to ConcurrentMap, and SecureCacheTestDriver doesn't cover them. This actually raises the question of whether we could provide our own implementations while still keeping compatibility with JDK6... > {noformat} > java.lang.Exception: Class org.infinispan.security.SecureCacheTestDriver needs to declare a method with the following signature: void testReplaceAll_BiFunction(SecureCache<String, String> cache) {} > at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:158) > Caused by: java.lang.NoSuchMethodException: org.infinispan.security.SecureCacheTestDriver.testReplaceAll_BiFunction(org.infinispan.security.SecureCache) > at java.lang.Class.getMethod(Class.java:1773) > at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:109) ... 20 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5004) ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5004?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5004: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1168174|https://bugzilla.redhat.com/show_bug.cgi?id=1168174] from ON_QA to VERIFIED > ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module > --------------------------------------------------------------------------------------- > > Key: ISPN-5004 > URL: https://issues.jboss.org/browse/ISPN-5004 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Alpha1 > > > It is currently located in infinispan-remote-query-server module, which is a mistake. Clients should not need to depend on the server module. > The interface should also be extended to add methods for retrieving the list of existing files and the errors status of each file. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5032) Create dedicated GetCacheEntryCommand to simplify code and save memory on GetKeyValueCommand

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5032?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5032: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1175300 > Create dedicated GetCacheEntryCommand to simplify code and save memory on GetKeyValueCommand > -------------------------------------------------------------------------------------------- > > Key: ISPN-5032 > URL: https://issues.jboss.org/browse/ISPN-5032 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Labels: jdg, performance > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > Class {{GetKeyValueCommand}} is a strong allocation hot spot and can be simplified as some fields are easily factored out. > There have been TODO comments in there for a while, I'm creating a dedicated {{GetCacheEntryCommand}} for when we need to fetch the whole entry rather than just the value. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4884: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from ASSIGNED to POST > Deployment scanner should be enabled to allow filter/converter jar deployment > ----------------------------------------------------------------------------- > > Key: ISPN-4884 > URL: https://issues.jboss.org/browse/ISPN-4884 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Final > > > When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built > Steps to Reproduce: > 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/ > 2. look at console output of server > 3. check if there is no output from deployment scanner > Current results: not output from deployment scanner, because it is not enabled > Expected results: we should see following output in console log > JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments > JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5094) Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5094?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5094: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/protostream/pull/14 > Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5094 > URL: https://issues.jboss.org/browse/ISPN-5094 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > org.infinispan.protostream.Message mechanism for supporting unknown fields is a bit too intrusive because it forces users to implement our interface in their domain model classes. > A better approach would be to have a similar interface implemented by the marshaller object instead. > {code} > public interface UnknownFieldSetHandler<T> { > UnknownFieldSet getUnknownFieldSet(T message); > void setUnknownFieldSet(T message, UnknownFieldSet unknownFieldSet); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5094) Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5094: ----------------------------------- Summary: Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields Key: ISPN-5094 URL: https://issues.jboss.org/browse/ISPN-5094 Project: Infinispan Issue Type: Feature Request Components: Remote Querying Reporter: Adrian Nistor Assignee: Adrian Nistor org.infinispan.protostream.Message mechanism for supporting unknown fields is a bit too intrusive because it forces users to implement our interface in their domain model classes. A better approach would be to have a similar interface implemented by the marshaller object instead. {code} public interface UnknownFieldSetHandler<T> { UnknownFieldSet getUnknownFieldSet(T message); void setUnknownFieldSet(T message, UnknownFieldSet unknownFieldSet); } {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5094) Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5094?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5094: -------------------------------- Status: Open (was: New) > Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5094 > URL: https://issues.jboss.org/browse/ISPN-5094 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > org.infinispan.protostream.Message mechanism for supporting unknown fields is a bit too intrusive because it forces users to implement our interface in their domain model classes. > A better approach would be to have a similar interface implemented by the marshaller object instead. > {code} > public interface UnknownFieldSetHandler<T> { > UnknownFieldSet getUnknownFieldSet(T message); > void setUnknownFieldSet(T message, UnknownFieldSet unknownFieldSet); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5019: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1163573|https://bugzilla.redhat.com/show_bug.cgi?id=1163573] from ON_QA to VERIFIED > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2014