December 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8462) Enable custom EntryMergePolicy deployments on the server

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8462?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8462: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.0.Beta2 Resolution: Done > Enable custom EntryMergePolicy deployments on the server > -------------------------------------------------------- > > Key: ISPN-8462 > URL: https://issues.jboss.org/browse/ISPN-8462 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Beta2, 9.2.0.Final > > > It should be possible for users to deploy custom implementations of the EntryMergePolicy interface in the same manner that custom cache stores are deployed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8522) PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8522?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8522. -------------------------------- Resolution: Done > PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology > -------------------------------------------------------------------------------------------------------- > > Key: ISPN-8522 > URL: https://issues.jboss.org/browse/ISPN-8522 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Beta2 > > > The current method for determining whether a split brain heal is occurring during an on merge event is wrong. Instead we should assume healing whenever one or more of the expected members is not in the membership of the maxTopology received. > Furthermore, we should also utilise the Union CH of all distinct CHs encountered for conflict resolution. This is necessary to ensure that we read the entries associated with all possible write owners before the rebalance occurs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8440) Enable ConflictResolution on partition merge with PreferConsistencyStrategy

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8440?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8440. -------------------------------- Resolution: Done > Enable ConflictResolution on partition merge with PreferConsistencyStrategy > --------------------------------------------------------------------------- > > Key: ISPN-8440 > URL: https://issues.jboss.org/browse/ISPN-8440 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.1.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > > Currently conflict resolution only occurs on a partition merge when the PreferAvailabilityStrategy is utilised (ALLOW_READ_WRITES). This should also occur when utilising the PreferConsistencyStrategy as it's possible for cache entries to become conflicted before a split-brain has been detected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8581) Fix ClusteredLog logging errors

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8581?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8581: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5645 > Fix ClusteredLog logging errors > ------------------------------- > > Key: ISPN-8581 > URL: https://issues.jboss.org/browse/ISPN-8581 > Project: Infinispan > Issue Type: Bug > Components: Clustered Locks > Reporter: Katia Aresti > Assignee: Katia Aresti > > ClusteredLocks are not logging properly, so error messages are displayed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8615) ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8615?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8615: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5645 > ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures > ------------------------------------------------------------------------------------- > > Key: ISPN-8615 > URL: https://issues.jboss.org/browse/ISPN-8615 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Beta1 > Reporter: Dan Berindei > Assignee: Katia Aresti > Labels: testsuite_stability > Fix For: 9.2.0.Beta2 > > > {noformat} > java.lang.AssertionError: > at org.infinispan.lock.impl.lock.ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout(ClusteredLockImplTest.java:94) > {noformat} > It happens rarely in CI, but I can reproduce it every time if I change the timeout to 100 ms. IMO the difference between {{testTryLockWithTimeoutAfterLockWithSmallTimeout}} and {{testTryLockWithTimeoutAfterLockWithBigTimeout}} should be that the former waits for {{tryLock(smalltimeout, unit)}} to time out before unlocking, and the latter waits for a little time before unlocking and checks that {{tryLock(bigtimeout, unit)}} still succeeds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8581) Fix ClusteredLog logging errors

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8581?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8581: ------------------------------- Status: Open (was: New) > Fix ClusteredLog logging errors > ------------------------------- > > Key: ISPN-8581 > URL: https://issues.jboss.org/browse/ISPN-8581 > Project: Infinispan > Issue Type: Bug > Components: Clustered Locks > Reporter: Katia Aresti > Assignee: Katia Aresti > > ClusteredLocks are not logging properly, so error messages are displayed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8615) ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8615?page=com.atlassian.jira.plugin.... ] Work on ISPN-8615 started by Katia Aresti. ------------------------------------------ > ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures > ------------------------------------------------------------------------------------- > > Key: ISPN-8615 > URL: https://issues.jboss.org/browse/ISPN-8615 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Beta1 > Reporter: Dan Berindei > Assignee: Katia Aresti > Labels: testsuite_stability > Fix For: 9.2.0.Beta2 > > > {noformat} > java.lang.AssertionError: > at org.infinispan.lock.impl.lock.ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout(ClusteredLockImplTest.java:94) > {noformat} > It happens rarely in CI, but I can reproduce it every time if I change the timeout to 100 ms. IMO the difference between {{testTryLockWithTimeoutAfterLockWithSmallTimeout}} and {{testTryLockWithTimeoutAfterLockWithBigTimeout}} should be that the former waits for {{tryLock(smalltimeout, unit)}} to time out before unlocking, and the latter waits for a little time before unlocking and checks that {{tryLock(bigtimeout, unit)}} still succeeds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8566) Rest server doesn't handle wildcards in the Accept header

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8566?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8566: ------------------------------------ Fix Version/s: (was: 9.1.4.Final) > Rest server doesn't handle wildcards in the Accept header > --------------------------------------------------------- > > Key: ISPN-8566 > URL: https://issues.jboss.org/browse/ISPN-8566 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.2.0.Beta1, 9.1.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Final > > > Typically a browser automatically adds multiple mime types in the accept header, like: > "text/html, application/xhtml+xml,\*/\*" > But when requesting a document in a cache encoded with protostream with the headers above, the response is > "Cannot find transcoder between application/xml and application/x-protostream" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.... ] Ryan Emerson reassigned ISPN-8634: ---------------------------------- Assignee: Ryan Emerson > Wildfly 11 fails to start with Infinispan 9.x modules installed > --------------------------------------------------------------- > > Key: ISPN-8634 > URL: https://issues.jboss.org/browse/ISPN-8634 > Project: Infinispan > Issue Type: Bug > Components: Integration > Affects Versions: 9.2.0.Beta1, 9.1.3.Final > Reporter: Alan Field > Assignee: Ryan Emerson > > A user on the forums reported that he got the following errors starting up Wildfly 11 with the Infinispan 9.1 modules installed and the extensions added to the {{standalone.xml}} file: > {noformat} > 14:25:14,340 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) > at org.jboss.as.server.ServerService.boot(ServerService.java:387) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370) > at java.lang.Thread.run(Thread.java:748) > Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.server.endpoint:ispn-9.2 > at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154) > at org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXml.java:131) > at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219) > at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126) > ... 3 more > Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146) > ... 11 more > Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module > at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195) > at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68) > at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126) > at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.sasl > at org.jboss.modules.Module.addPaths(Module.java:1217) > at org.jboss.modules.Module.link(Module.java:1573) > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1601) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:287) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271) > at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177) > ... 8 more > {noformat} > This also happens with the 9.2.0.Beta1 modules. Wildfly 11 includes a {{bin/client/README-EJB-JMS.txt}} file that states: > {noformat} > jboss-client.jar is a combined client jar for WildFly, for use in non-maven environments. This jar should be used > with standalone clients only, not with deployments are that deployed to a WildFly instance. > This jar contains the classes required for remote JMS and EJB usage, and consists of the following shaded artifacts: > org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec > org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec > org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec > com.google.guava:guava > commons-beanutils:commons-beanutils > commons-collections:commons-collections > io.netty:netty-all > org.apache.activemq:artemis-commons > org.apache.activemq:artemis-core-client > org.apache.activemq:artemis-hqclient-protocol > org.apache.activemq:artemis-jms-client > org.jboss:jboss-ejb-client > org.jboss:jboss-remote-naming > org.jboss.logging:jboss-logging > org.jboss.marshalling:jboss-marshalling > org.jboss.marshalling:jboss-marshalling-river > org.jboss.remoting:jboss-remoting > org.jboss.remotingjmx:remoting-jmx > org.jboss.sasl:jboss-sasl > org.jboss.xnio:xnio-api > org.jboss.xnio:xnio-nio > org.jgroups:jgroups > org.slf4j:slf4j-api > org.slf4j:jcl-over-slf4j > Maven users should not use this jar, but should use the following BOM dependencies instead > <dependencies> > <dependency> > <groupId>org.wildfly</groupId> > <artifactId>wildfly-ejb-client-bom</artifactId> > <type>pom</type> > </dependency> > <dependency> > <groupId>org.wildfly</groupId> > <artifactId>wildfly-jms-client-bom</artifactId> > <type>pom</type> > </dependency> > </dependencies> > This is because using maven with a shaded jar has a very high chance of causing class version conflicts, which is why > we do not publish this jar to the maven repository. > {noformat} > The modules will need to modified to deal with this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7599) Add Jolokia to the server

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7599?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-7599: ----------------------------------------- https://github.com/infinispan/infinispan/pull/5586 was merged on Infinispan, leaving this JIRA opened as there seems to be more work to do. > Add Jolokia to the server > ------------------------- > > Key: ISPN-7599 > URL: https://issues.jboss.org/browse/ISPN-7599 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud, Server > Reporter: Sebastian Łaskawiec > Assignee: Vladimir Blagojevic > Priority: Critical > Fix For: 9.2.0.Final > > > The server should support exposing [Jolokia|https://jolokia.org] endpoints. The support should be disabled by default and there should be possibility to enable it using an environmental variable. > OpenShift has special Administration Console for Jolokia-enabled endpoints. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2017