January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-2886: -------------------------------------- Description: Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) h2. Update This also happens when using CDI Extension in Library mode with Wildfly. Attached Pull Request fixes that case. was: Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Sebastian Łaskawiec > Priority: Minor > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) > h2. Update > This also happens when using CDI Extension in Library mode with Wildfly. Attached Pull Request fixes that case. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-2886: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3238 > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Sebastian Łaskawiec > Priority: Minor > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5180) Hot Rod type converter in Compatibility should not marshall a byte[] again

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5180?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5180: ----------------------------------- Status: Open (was: New) > Hot Rod type converter in Compatibility should not marshall a byte[] again > -------------------------------------------------------------------------- > > Key: ISPN-5180 > URL: https://issues.jboss.org/browse/ISPN-5180 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.3.Final, 7.1.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Labels: compatibility > Fix For: 7.1.0.Final > > > When compatibility is enabled, storing a java serialized object with REST, and then retrieving it with Hot Rod results in byte[] being returned instead of the deserilialized object: > {code}java.lang.AssertionError: > Expected :org.infinispan.it.compatibility.EmbeddedRestHotRodTest$Person@22cd6f > Actual :[B@2ff9eb2a > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testCustomObjectRestPutHotRodEmbeddedGet(EmbeddedRestHotRodTest.java:217) > {code} > This is because when the entry is retrieved by Hot Rod and it's going to marshall it for sending it back to the client, it should check if the entry is already a byte[], in which case it should not touch it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5180) Hot Rod type converter in Compatibility should not marshall a byte[] again

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5180?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5180: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3237 > Hot Rod type converter in Compatibility should not marshall a byte[] again > -------------------------------------------------------------------------- > > Key: ISPN-5180 > URL: https://issues.jboss.org/browse/ISPN-5180 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.3.Final, 7.1.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Labels: compatibility > Fix For: 7.1.0.Final > > > When compatibility is enabled, storing a java serialized object with REST, and then retrieving it with Hot Rod results in byte[] being returned instead of the deserilialized object: > {code}java.lang.AssertionError: > Expected :org.infinispan.it.compatibility.EmbeddedRestHotRodTest$Person@22cd6f > Actual :[B@2ff9eb2a > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testCustomObjectRestPutHotRodEmbeddedGet(EmbeddedRestHotRodTest.java:217) > {code} > This is because when the entry is retrieved by Hot Rod and it's going to marshall it for sending it back to the client, it should check if the entry is already a byte[], in which case it should not touch it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5182) Narayana 5 requires JTA 1.2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5182?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5182: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3236 > Narayana 5 requires JTA 1.2 > --------------------------- > > Key: ISPN-5182 > URL: https://issues.jboss.org/browse/ISPN-5182 > Project: Infinispan > Issue Type: Bug > Components: Build process, Transactions > Affects Versions: 7.1.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 7.1.0.Final > > > The upgrade to Narayana 5.0.x done in ISPN-3824 has caused many failures in the testsuite since it needs the JTA 1.2 APIs instead of JTA 1.1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5182) Narayana 5 requires JTA 1.2

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5182: ------------------------------------- Summary: Narayana 5 requires JTA 1.2 Key: ISPN-5182 URL: https://issues.jboss.org/browse/ISPN-5182 Project: Infinispan Issue Type: Bug Components: Build process, Transactions Affects Versions: 7.1.0.CR2 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Blocker Fix For: 7.1.0.Final The upgrade to Narayana 5.0.x done in ISPN-3824 has caused many failures in the testsuite since it needs the JTA 1.2 APIs instead of JTA 1.1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5182) Narayana 5 requires JTA 1.2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5182?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5182: ---------------------------------- Status: Open (was: New) > Narayana 5 requires JTA 1.2 > --------------------------- > > Key: ISPN-5182 > URL: https://issues.jboss.org/browse/ISPN-5182 > Project: Infinispan > Issue Type: Bug > Components: Build process, Transactions > Affects Versions: 7.1.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 7.1.0.Final > > > The upgrade to Narayana 5.0.x done in ISPN-3824 has caused many failures in the testsuite since it needs the JTA 1.2 APIs instead of JTA 1.1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5181) Map/Reduce fails when CDI is not on the classpath

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5181: ------------------------------------- Summary: Map/Reduce fails when CDI is not on the classpath Key: ISPN-5181 URL: https://issues.jboss.org/browse/ISPN-5181 Project: Infinispan Issue Type: Bug Components: Distributed Execution and Map/Reduce Affects Versions: 7.1.0.CR2, 7.0.3.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.1.0.Final, 7.0.4.Final Similar to ISPN-5121 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-2886: ------------------------------------------- The setting is in place. Here is the code sample: {code} @Produces @ApplicationScoped public EmbeddedCacheManager greetingCacheManager(@GreetingCache Configuration configuration) { GlobalConfiguration globalConfiguration = new GlobalConfigurationBuilder().globalJmxStatistics().allowDuplicateDomains(true).build(); return new DefaultCacheManager(globalConfiguration, configuration); } {code} > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Sebastian Łaskawiec > Priority: Minor > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5180) Hot Rod type converter in Compatibility should not marshall a byte[] again

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5180: -------------------------------------- Summary: Hot Rod type converter in Compatibility should not marshall a byte[] again Key: ISPN-5180 URL: https://issues.jboss.org/browse/ISPN-5180 Project: Infinispan Issue Type: Bug Components: Remote Protocols Affects Versions: 7.1.0.CR2, 7.0.3.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Critical Fix For: 7.1.0.Final When compatibility is enabled, storing a java serialized object with REST, and then retrieving it with Hot Rod results in byte[] being returned instead of the deserilialized object: {code}java.lang.AssertionError: Expected :org.infinispan.it.compatibility.EmbeddedRestHotRodTest$Person@22cd6f Actual :[B@2ff9eb2a at org.testng.AssertJUnit.fail(AssertJUnit.java:59) at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testCustomObjectRestPutHotRodEmbeddedGet(EmbeddedRestHotRodTest.java:217) {code} This is because when the entry is retrieved by Hot Rod and it's going to marshall it for sending it back to the client, it should check if the entry is already a byte[], in which case it should not touch it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 January 2015