[JBoss JIRA] (ISPN-3531) LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
by Tomas Sykora (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Tomas Sykora commented on ISPN-3531:
------------------------------------
At very first sight it looks like it should really impact only MassIndexer stuff... it means only 1 particular operation which is callable using JON UI and Infinispan Library plugin.
Names in plugin etc. are generated automatically according to MBean names and managed operations, so once it renames, plugin should be ok with that.
It can only affects my testing but I hope in a positive way. From failing to passing (after very small modification) :)
I will thoroughly dive into it probably tomorrow, Thursday (if we are in a hurry, let me know, I will prioritize it)
> LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The ObjectName used for query related MBeans does not contain the name of the cache manager as an attribute to ensure disambiguation. Thus, if two cache managers are configured to share the same JMX domain their query related MBean names would clash and shutting down one of the managers would also unregister the MBeans belonging to the other(s).
--
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, 5 months
[JBoss JIRA] (ISPN-3318) Migrate data from one cache store to another
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3318?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3318:
--------------------------------------
Hi Galder,
your commit dbf63e2d4b21aaf8a7a5eda1dca1f88c72fc9070
concretely: git diff 43f82b7 dbf63e2 core/src/main/java/org/infinispan/util/logging/Log.java (on current master)
made the infinispan-cachestore-rest build unfunctional
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-qe-build-infinisp...
{code}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.0:compile (default-compile) on project infinispan-cachestore-rest: Compilation failure: Compilation failure:
[ERROR] Only one message with the same format parameters is allowed.
[ERROR] /home_local/workspace/jdg-qe-build-infinispan60-snapshot-auto/infinispan-cachestore-rest/src/main/java/org/infinispan/persistence/rest/logging/Log.java:[60,19] Only one message with the same format parameters is allowed.
[ERROR] /home_local/workspace/jdg-qe-build-infinispan60-snapshot-auto/infinispan-cachestore-rest/src/main/java/org/infinispan/persistence/rest/logging/Log.java:[64,9] Only one message with the same format parameters is allowed.
[ERROR] /home_local/workspace/jdg-qe-build-infinispan60-snapshot-auto/infinispan-cachestore-rest/src/main/java/org/infinispan/persistence/rest/logging/Log.java: Only one message with the same format parameters is allowed.
{code}
could you please fix this in the rest cachestore as well ? (it blocks building of infinispan-server for perf regression tests)
> Migrate data from one cache store to another
> --------------------------------------------
>
> Key: ISPN-3318
> URL: https://issues.jboss.org/browse/ISPN-3318
> Project: Infinispan
> Issue Type: Task
> Components: Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> Find a generic way to transfer data from one cache store to another, which could involve different Infinispan versions. This is handy to migrate file cache store based users to single file cache store (ISPN-2806).
> Ideally, this should be added as a recipe for rolling upgrades.
--
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, 5 months
[JBoss JIRA] (ISPN-3698) Failure during concurrent restart of cache/manager
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3698?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3698:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2213
> Failure during concurrent restart of cache/manager
> --------------------------------------------------
>
> Key: ISPN-3698
> URL: https://issues.jboss.org/browse/ISPN-3698
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.2.7.Final, 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.8.Final, 6.0.0.Final
>
>
> These failures prevent the cache from starting successfully, and consequently the redeploy to fail. There are 3 stack traces of note in the logs:
> {noformat}
> 15:05:32,044 ERROR [org.jgroups.blocks.RequestCorrelator] (OOB-20,shared=udp) failed unmarshalling buffer into return value: java.lang.NullPointerException
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:150)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355) [jboss-marshalling-river-1.4.2.Final.jar:1.4.2.Final]
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) [jboss-marshalling-river-1.4.2.Final.jar:1.4.2.Final]
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:96)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> at org.jgroups.JChannel.up(JChannel.java:708)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> at org.jgroups.protocols.RSVP.up(RSVP.java:187)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:698)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:184)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2534)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1389)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1540)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 15:43:48,482 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.infinispan.ejb.remote-connector-client-mappings: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.remote-connector-client-mappings: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:871)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:666)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: java.lang.NullPointerException
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:557)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:277)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:91)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 18 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:150)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:96)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> at org.jgroups.JChannel.up(JChannel.java:708)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> at org.jgroups.protocols.RSVP.up(RSVP.java:187)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:698)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:184)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2534)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1389)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1540)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 15:43:48,482 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.infinispan.ejb.remote-connector-client-mappings: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.remote-connector-client-mappings: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:871)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:666)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: java.lang.NullPointerException
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:557)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:277)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:91)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 18 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:150)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:96)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> at org.jgroups.JChannel.up(JChannel.java:708)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> at org.jgroups.protocols.RSVP.up(RSVP.java:187)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:698)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:184)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2534)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1389)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1540)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)15:43:48,502 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 59) MSC000001: Failed to start service jboss.infinispan.ejb.repl: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.repl: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:871)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:666)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:557)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:277)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:91)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 18 more
> Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> ... 27 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getObjectWriter(JBossMarshaller.java:145)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:142)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:115) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:78)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:72)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:331)
> ... 29 more
> Caused by: an exception which occurred:
> in object org.infinispan.topology.CacheTopologyControlCommand@f80b63c
> [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {noformat}
--
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, 5 months
[JBoss JIRA] (ISPN-3531) LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3531:
-------------------------------------
[~tsykora], [~william.burns] I highly suspect this also impacts JON/RHQ but could not find any source code references to ObjectNames having type=Query in the plugin. Any help would be appreciated.
> LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The ObjectName used for query related MBeans does not contain the name of the cache manager as an attribute to ensure disambiguation. Thus, if two cache managers are configured to share the same JMX domain their query related MBean names would clash and shutting down one of the managers would also unregister the MBeans belonging to the other(s).
--
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, 5 months
[JBoss JIRA] (ISPN-3697) Improved lifecycle control of JGroupsChannelLookup
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3697?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3697:
------------------------------------
I think it's too late for SPI changes in 6.0 now.
If creating a new Channel on restart is not an option, I guess your best option is indeed to return a Channel wrapper that disables close() from getJGroupsChannel(). But I don't think you need another method to do the actual closing, your JGroups service should still have access to the original Channel.
For the future, I guess I would prefer to see Wildfly take over the management of the channel completely. In principle, a new node joining the JGroups view should not influence the running Infinispan caches in any way until it also starts a cache - although ATM there may be some problems with broadcast sync RPCs - e.g. writes in replicated+sync caches and ClusterTopologyManager's recovery process (when the coordinator leaves the cluster).
> Improved lifecycle control of JGroupsChannelLookup
> --------------------------------------------------
>
> Key: ISPN-3697
> URL: https://issues.jboss.org/browse/ISPN-3697
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 6.0.0.Final
>
>
> Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
> In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not, e.g.
> https://issues.jboss.org/browse/WFLY-2458
> To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
> So what I propose is the following:
> boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
> boolean shouldDisconnect();
> boolean shouldClose();
--
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, 5 months
[JBoss JIRA] (ISPN-3531) LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3531:
--------------------------------
Summary: LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers (was: LifecycleManager of query module keeps references to per cache manager resources (jmx related))
Description: The ObjectName used for query related MBeans does not contain the name of the cache manager as an attribute to ensure disambiguation. Thus, if two cache managers are configured to share the same JMX domain their query related MBean names would clash and shutting down one of the managers would also unregister the MBeans belonging to the other(s). (was: The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains.
Cache stop event also does not seem to be processed correctly.)
Edited title and description to match the new findings.
> LifecycleManager of query module inadvertently unregisters MBeans belonging to other cache managers
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The ObjectName used for query related MBeans does not contain the name of the cache manager as an attribute to ensure disambiguation. Thus, if two cache managers are configured to share the same JMX domain their query related MBean names would clash and shutting down one of the managers would also unregister the MBeans belonging to the other(s).
--
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, 5 months