May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5438) Filter out example jgroups configuration from uber jar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5438?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5438: ---------------------------------- Status: Open (was: New) > Filter out example jgroups configuration from uber jar > ------------------------------------------------------ > > Key: ISPN-5438 > URL: https://issues.jboss.org/browse/ISPN-5438 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.2.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The jgroups jar contains a ton of example configs which should really be filterted out to avoid confusion. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5438) Filter out example jgroups configuration from uber jar

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5438: ------------------------------------- Summary: Filter out example jgroups configuration from uber jar Key: ISPN-5438 URL: https://issues.jboss.org/browse/ISPN-5438 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 7.2.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant The jgroups jar contains a ton of example configs which should really be filterted out to avoid confusion. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5438) Filter out example jgroups configuration from uber jar

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5438?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5438: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1188617 > Filter out example jgroups configuration from uber jar > ------------------------------------------------------ > > Key: ISPN-5438 > URL: https://issues.jboss.org/browse/ISPN-5438 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.2.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The jgroups jar contains a ton of example configs which should really be filterted out to avoid confusion. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5437) Hot Rod getAll() sometimes fails Unable to unmarshall bytes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5437?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-5437: ----------------------------------- Assignee: William Burns > Hot Rod getAll() sometimes fails Unable to unmarshall bytes > ----------------------------------------------------------- > > Key: ISPN-5437 > URL: https://issues.jboss.org/browse/ISPN-5437 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: William Burns > > fails with > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 034303ec21acedb3a35eaf > {noformat} > usually happen with ~10k of entries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5437) Hot Rod getAll() sometimes fails Unable to unmarshall bytes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5437?page=com.atlassian.jira.plugin.... ] Work on ISPN-5437 started by William Burns. ------------------------------------------- > Hot Rod getAll() sometimes fails Unable to unmarshall bytes > ----------------------------------------------------------- > > Key: ISPN-5437 > URL: https://issues.jboss.org/browse/ISPN-5437 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: William Burns > > fails with > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 034303ec21acedb3a35eaf > {noformat} > usually happen with ~10k of entries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5437) Hot Rod getAll() sometimes fails Unable to unmarshall bytes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5437?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5437: -------------------------------- Status: Open (was: New) > Hot Rod getAll() sometimes fails Unable to unmarshall bytes > ----------------------------------------------------------- > > Key: ISPN-5437 > URL: https://issues.jboss.org/browse/ISPN-5437 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > > fails with > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 034303ec21acedb3a35eaf > {noformat} > usually happen with ~10k of entries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5437) Hot Rod getAll() sometimes fails Unable to unmarshall bytes

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5437?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5437: ---------------------------------- Summary: Hot Rod getAll() sometimes fails Unable to unmarshall bytes (was: Hot Rod getAll() sometimes fails {{Unable to unmarshall bytes}}) > Hot Rod getAll() sometimes fails Unable to unmarshall bytes > ----------------------------------------------------------- > > Key: ISPN-5437 > URL: https://issues.jboss.org/browse/ISPN-5437 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > > fails with > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 034303ec21acedb3a35eaf > {noformat} > usually happen with ~10k of entries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5437) Hot Rod getAll() sometimes fails {{Unable to unmarshall bytes}}

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-5437: ------------------------------------- Summary: Hot Rod getAll() sometimes fails {{Unable to unmarshall bytes}} Key: ISPN-5437 URL: https://issues.jboss.org/browse/ISPN-5437 Project: Infinispan Issue Type: Bug Components: Server Reporter: Vojtech Juranek fails with {noformat} org.infinispan.client.hotrod.exceptions.HotRodClientException: ISPN004034: Unable to unmarshall bytes 034303ec21acedb3a35eaf {noformat} usually happen with ~10k of entries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5106) Deadlock on GlobalComponentRegistry when starting a cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5106?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5106: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1217380|https://bugzilla.redhat.com/show_bug.cgi?id=1217380] from NEW to ASSIGNED > Deadlock on GlobalComponentRegistry when starting a cluster > ----------------------------------------------------------- > > Key: ISPN-5106 > URL: https://issues.jboss.org/browse/ISPN-5106 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > Attachments: dumps_and_logs.zip > > > We have a test which starts 4 server nodes, and sometimes they fail to complete the startup. This happens with the current snapshot. > It appears there's a deadlock on intrinsic locks on GlobalComponentRegistry, since the CacheTopologyControlCommand.POLICY_GET_STATUS is sent with the lock acquired but this lock is also needed for injecting dependencies when the command is processed on the remote node. > Here are the relevant parts from the dumps, node02: > {code} > "remote-thread--p3-t1" daemon prio=10 tid=0x00007f7a00002800 nid=0x487f waiting for monitor entry [0x00007f796bbfa000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:262) > - waiting to lock <0x000000060365b6b8> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227) > at org.infinispan.factories.AbstractComponentRegistry.wireDependencies(AbstractComponentRegistry.java:132) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$2.run(GlobalInboundInvocationHandler.java:156) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Locked ownable synchronizers: > - <0x0000000615af46d0> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "MSC service thread 1-16" prio=10 tid=0x00007f79ec071800 nid=0x4839 waiting on condition [0x00007f7a40239000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000614d47e60> (a java.util.concurrent.FutureTask) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:422) > at java.util.concurrent.FutureTask.get(FutureTask.java:199) > at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:432) > at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:385) > at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:368) > at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:359) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:281) > - locked <0x000000060420d4a8> (a java.lang.Object) > at org.infinispan.topology.ClusterTopologyManagerImpl.start(ClusterTopologyManagerImpl.java:103) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > - locked <0x000000060365b6b8> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:221) > - locked <0x000000060365b6b8> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:580) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:546) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:423) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:437) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:116) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:113) > at org.infinispan.security.Security.doPrivileged(Security.java:76) > at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:60) > at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:121) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:79) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Locked ownable synchronizers: > - <0x0000000653444750> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} > and node03 > {code} > "remote-thread--p3-t1" daemon prio=10 tid=0x00007f016c079000 nid=0x1a43 waiting for monitor entry [0x00007f0114396000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:262) > - waiting to lock <0x0000000609c2bf50> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227) > at org.infinispan.factories.AbstractComponentRegistry.wireDependencies(AbstractComponentRegistry.java:132) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$2.run(GlobalInboundInvocationHandler.java:156) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Locked ownable synchronizers: > - <0x0000000615a05750> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "MSC service thread 1-16" prio=10 tid=0x00007f015c071800 nid=0x19ff waiting on condition [0x00007f01b0558000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000615025bb0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) > at org.jgroups.util.CondVar.waitFor(CondVar.java:64) > at org.jgroups.blocks.Request.waitForResults(Request.java:195) > at org.jgroups.blocks.Request.responsesComplete(Request.java:181) > at org.jgroups.blocks.Request.execute(Request.java:89) > at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:409) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:374) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:188) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:562) > at org.infinispan.topology.ClusterTopologyManagerImpl.start(ClusterTopologyManagerImpl.java:112) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > - locked <0x0000000609c2bf50> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:221) > - locked <0x0000000609c2bf50> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:580) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:546) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:423) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:437) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:116) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:113) > at org.infinispan.security.Security.doPrivileged(Security.java:76) > at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:60) > at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:121) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:79) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Locked ownable synchronizers: > - <0x00000006534e9628> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5429) Cluster CacheEventFilterConverter wrapping leads to double callbacks

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5429?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5429: ---------------------------------------- ISPN-5436 needs to be sorted out to figure out why double callbacks are still happening. > Cluster CacheEventFilterConverter wrapping leads to double callbacks > -------------------------------------------------------------------- > > Key: ISPN-5429 > URL: https://issues.jboss.org/browse/ISPN-5429 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.2.0.CR1, 7.1.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > This was spotted by Pierre Sutra from University of Neuchatel: > When a CacheEventFilterConverter is registered with remote event listeners, and running in a cluster, once the CacheEventFilterConverter instance is replicated, the notion that its both a filter AND converter is lost because BaseCacheEntryListenerInvocation's constructor determines that {{filterAndConvert}} is false. > The reason this happens is because after clustering it, the ClusterListenerReplicateCallable.call() wraps the {{filter}} into an {{AbstractCacheEventFilterConverter}} implementation, which does not keep the referential equality that BaseCacheEntryListenerInvocation's constructor checks. > A simple way to avoid this is to implement {{equals}} in the AbstractCacheEventFilterConverter implementation and use referential equality. Then, switching BaseCacheEntryListenerInvocation's constructors referential equality by a call to {{equals}} is enough to solve the issue. > The reason this bug was detected is because without a fix for it, the filter + converter gets two callbacks instead of one. I've added tests to verify that the number callbacks expected is the correct one. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015