January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2775) CacheStore XSDs are broken

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2775: ------------------------------------- Summary: CacheStore XSDs are broken Key: ISPN-2775 URL: https://issues.jboss.org/browse/ISPN-2775 Project: Infinispan Issue Type: Bug Components: Configuration, Loaders and Stores Affects Versions: 5.2.0.CR3 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.Final The store XSDs don't declare their top-level elements as such but only as complexTypes. This makes it impossible to validate XML files in IDEs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2759) RHQ plugin + JON, problems with invoking operations on cache / cache manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2759?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2759: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 904140|https://bugzilla.redhat.com/show_bug.cgi?id=904140] from NEW to MODIFIED > RHQ plugin + JON, problems with invoking operations on cache / cache manager > ---------------------------------------------------------------------------- > > Key: ISPN-2759 > URL: https://issues.jboss.org/browse/ISPN-2759 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.CR3 > Environment: Fresh installation of JON 3.1.2.GA + community RHQ plugin for library mode + community distribution server built from upstream (already containing: https://github.com/infinispan/infinispan/pull/1595). This bug was experienced before this PR already. > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > > In JON we can see changing statistics for caches without any problems. Monitoring looks to be ok. > Problems occurred while issuing any operation. > For example: > *start cache issued on DefaultCacheManager (JON's popup exception window output):* > java.lang.NullPointerException > at org.rhq.plugins.jmx.MBeanResourceComponent.loadBean(MBeanResourceComponent.java:175) > at org.rhq.plugins.jmx.MBeanResourceComponent.getEmsBean(MBeanResourceComponent.java:137) > at org.rhq.plugins.jmx.MBeanResourceComponent.invokeOperation(MBeanResourceComponent.java:524) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > *stop cache issued on cache* > java.lang.NullPointerException > at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:190) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > *ISPN console with trace logging enabled says:* > 2013-01-25 15:24:27,351 DEBUG [CacheImpl] (RMI TCP Connection(8)-127.0.0.1) Stopping cache ___defaultcache on null > 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) Wait for on-going transactions to finish for 30 seconds. > 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) All transactions terminated > Other operations seem to be unavailable too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2738) Joining node ignored by hotrod clients in REPL clustering mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2738?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2738: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 902794|https://bugzilla.redhat.com/show_bug.cgi?id=902794] Verified for JDG 6.1.0.ER10 > Joining node ignored by hotrod clients in REPL clustering mode > -------------------------------------------------------------- > > Key: ISPN-2738 > URL: https://issues.jboss.org/browse/ISPN-2738 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.CR2 > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.CR3 > > > resilience 4-3-4 REPL mode for JDG 6.1.0.ER9 (infinispan 5.2.0.CR2): > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > after rejoin of killed node the load is not redistributed to all three nodes again -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2738) Joining node ignored by hotrod clients in REPL clustering mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2738?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2738: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 902794|https://bugzilla.redhat.com/show_bug.cgi?id=902794] from ON_QA to VERIFIED > Joining node ignored by hotrod clients in REPL clustering mode > -------------------------------------------------------------- > > Key: ISPN-2738 > URL: https://issues.jboss.org/browse/ISPN-2738 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.CR2 > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.CR3 > > > resilience 4-3-4 REPL mode for JDG 6.1.0.ER9 (infinispan 5.2.0.CR2): > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > after rejoin of killed node the load is not redistributed to all three nodes again -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2647: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 902462|https://bugzilla.redhat.com/show_bug.cgi?id=902462] Still present in JDG 6.1.0.ER10: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 5.2.0.CR3 > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2647) ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2647?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2647: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 902462|https://bugzilla.redhat.com/show_bug.cgi?id=902462] from ON_QA to ASSIGNED > ReplaceCommand does not perform any modifications if the entry was not yet transfered during rehashing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2647 > URL: https://issues.jboss.org/browse/ISPN-2647 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 5.2.0.CR3 > > > The local data container does not have the entry yet so the ReplaceCommand fails. See BaseDistStateTransferConsistencyTest.testReplace() and BaseReplStateTransferConsistencyTest.testReplace(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2759) RHQ plugin + JON, problems with invoking operations on cache / cache manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2759?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2759: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> made a comment on [bug 904140|https://bugzilla.redhat.com/show_bug.cgi?id=904140] ER10 does NOT contain fix for this. (Changes of CacheComponent.java class in rhq-plugin module didn't go into CR3 (= neither ER10). Anyway infinispan upstream master contains this fix. > RHQ plugin + JON, problems with invoking operations on cache / cache manager > ---------------------------------------------------------------------------- > > Key: ISPN-2759 > URL: https://issues.jboss.org/browse/ISPN-2759 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.CR3 > Environment: Fresh installation of JON 3.1.2.GA + community RHQ plugin for library mode + community distribution server built from upstream (already containing: https://github.com/infinispan/infinispan/pull/1595). This bug was experienced before this PR already. > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > > In JON we can see changing statistics for caches without any problems. Monitoring looks to be ok. > Problems occurred while issuing any operation. > For example: > *start cache issued on DefaultCacheManager (JON's popup exception window output):* > java.lang.NullPointerException > at org.rhq.plugins.jmx.MBeanResourceComponent.loadBean(MBeanResourceComponent.java:175) > at org.rhq.plugins.jmx.MBeanResourceComponent.getEmsBean(MBeanResourceComponent.java:137) > at org.rhq.plugins.jmx.MBeanResourceComponent.invokeOperation(MBeanResourceComponent.java:524) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > *stop cache issued on cache* > java.lang.NullPointerException > at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:190) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > *ISPN console with trace logging enabled says:* > 2013-01-25 15:24:27,351 DEBUG [CacheImpl] (RMI TCP Connection(8)-127.0.0.1) Stopping cache ___defaultcache on null > 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) Wait for on-going transactions to finish for 30 seconds. > 2013-01-25 15:24:27,357 DEBUG [TransactionTable] (RMI TCP Connection(8)-127.0.0.1) All transactions terminated > Other operations seem to be unavailable too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2699) Failed ping on startup can leave socket dirty

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2699?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2699: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1624 > Failed ping on startup can leave socket dirty > --------------------------------------------- > > Key: ISPN-2699 > URL: https://issues.jboss.org/browse/ISPN-2699 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.2.0.Final > > > Ping on startup in TransportObjectFactory.makeObject does not check the return value of ping operation, neither the tcpTransport.isValid(). > Therefore, if a HotRodClientException is thrown when the response header is read from socket, the socket is left in a dirty state. > In our case this resulted in reading response to previous request (the request was written but the response was not read due to some timeout and then, when another request was executed it read the response to the first request). This caused {{ISPN004004: Invalid message id. Expected 2930 and received 212}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2106) Leave messages should be SYNC to prevent the externalizer shutting down before the message is serialized

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2106?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2106: ------------------------------------- Those disabled tests actually work. Enabling them now. > Leave messages should be SYNC to prevent the externalizer shutting down before the message is serialized > -------------------------------------------------------------------------------------------------------- > > Key: ISPN-2106 > URL: https://issues.jboss.org/browse/ISPN-2106 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Reporter: Galder Zamarreño > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 5.1.x > > > This was first detected in an unstable test (see below). > The consequence of this test is that it adds stability to restarting a cache. > See: > https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/org.in... > and > https://infinispan.ci.cloudbees.com/job/Infinispan-5.1.x-JDK6-tcp/org.inf... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2697: ---------------------------------------- Talking to Bela yesterday, adding the flag is the quickest solution here and I've narrowed down the use case when to use the flag, so it will be accompanied by plenty of javadoc and I'll blog about it. That said, a solution that doesn't require the flag would be ideal, as Dan suggested, that allows STABLE to cover this situations given the replication timeout value. > HotRodServer startup fails when its record cannot be inserted into topology cache > --------------------------------------------------------------------------------- > > Key: ISPN-2697 > URL: https://issues.jboss.org/browse/ISPN-2697 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.2.0.Final > > > When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}). > However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013