October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4819) Server error and console pages are broken

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4819: ------------------------------------- Summary: Server error and console pages are broken Key: ISPN-4819 URL: https://issues.jboss.org/browse/ISPN-4819 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 7.0.0.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.0.0.CR2 When accessing the server management port (http://localhost:9999) the user is presented with a blank error page instead of being served the actual content. The content itself needs an overhaul -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4818) Allow creation of Infinispan caches as OSGi managed service

by Ion Savin (JIRA)

Ion Savin created ISPN-4818: ------------------------------- Summary: Allow creation of Infinispan caches as OSGi managed service Key: ISPN-4818 URL: https://issues.jboss.org/browse/ISPN-4818 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 7.0.0.CR1 Reporter: Ion Savin Assignee: Ion Savin -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4011) Make it possible to use 'remote-jmx' protocol inside Karaf

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4011?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4011: -------------------------------- Fix Version/s: (was: 7.0.0.Final) > Make it possible to use 'remote-jmx' protocol inside Karaf > ---------------------------------------------------------- > > Key: ISPN-4011 > URL: https://issues.jboss.org/browse/ISPN-4011 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Martin Gencur > Labels: 630 > > This is needed so remote-query clients can register protobuf schemas via jmx. Currently this was circumvented by creating a separate stand-alone app (ProtofileRegistrar) that runs outside Karaf before the actual test. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4011) Make it possible to use 'remote-jmx' protocol inside Karaf

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4011?page=com.atlassian.jira.plugin.... ] Adrian Nistor resolved ISPN-4011. --------------------------------- Resolution: Won't Fix Closing this because ISPN-4357 provides a better alternative mechanism that does not require JMX. > Make it possible to use 'remote-jmx' protocol inside Karaf > ---------------------------------------------------------- > > Key: ISPN-4011 > URL: https://issues.jboss.org/browse/ISPN-4011 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Martin Gencur > Labels: 630 > Fix For: 7.0.0.Final > > > This is needed so remote-query clients can register protobuf schemas via jmx. Currently this was circumvented by creating a separate stand-alone app (ProtofileRegistrar) that runs outside Karaf before the actual test. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4693: ------------------------------------ I think this can only happen if B keeps seeing the cluster during the split, or at least doesn't manage to install a cache topology. Otherwise {{TransactionTable.cleanupStaleTransactions()}} would roll back txs originating from A. > Locks acquired before a partition will never be released > -------------------------------------------------------- > > Key: ISPN-4693 > URL: https://issues.jboss.org/browse/ISPN-4693 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Consider the following case: > 1. A prepares a transaction for key K on nodes B and C. > 2. The primary owner B acquires and registers this lock. > 3. The cluster partitions and A,C remain in partition one, and B in a separate partition. > 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B. > 5. B rejoins the cluster. It still has a lock acquired for key K. > This can lead to a lock being acquired indefinitely. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4693: ------------------------------------ I think this can only happen if B doesn't notice the split, otherwise {{TransactionTable.cleanupStaleTransactions()}} will remove the transactions originating from A. OTOH, this can cause problems even if B was a backup owner for K: having a remote tx with a lower topology id will slow down lock acquisition for any key, because each existing transaction must be checked for backup locks (i.e. locks acquired on other nodes). > Locks acquired before a partition will never be released > -------------------------------------------------------- > > Key: ISPN-4693 > URL: https://issues.jboss.org/browse/ISPN-4693 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Consider the following case: > 1. A prepares a transaction for key K on nodes B and C. > 2. The primary owner B acquires and registers this lock. > 3. The cluster partitions and A,C remain in partition one, and B in a separate partition. > 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B. > 5. B rejoins the cluster. It still has a lock acquired for key K. > This can lead to a lock being acquired indefinitely. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4817) Cluster Listener replication of listener to remote dist nodes needs privilege action

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4817?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4817: ------------------------------------- Actually I am not quite sure if the Cache provided is wrapped, second thinking it most likely is not. > Cluster Listener replication of listener to remote dist nodes needs privilege action > ------------------------------------------------------------------------------------ > > Key: ISPN-4817 > URL: https://issues.jboss.org/browse/ISPN-4817 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.CR2 > > > The ClusterListenerReplicateCallable needs to add the listener in a privileged block so that it can work properly. > I was also thinking if we need to change all of our messages to send along the current Subject so it can be properly applied to remote invocations as well. In this case we wouldn't need to wrap the listener invocation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4817) Cluster Listener replication of listener to remote dist nodes needs privilege action

by William Burns (JIRA)

William Burns created ISPN-4817: ----------------------------------- Summary: Cluster Listener replication of listener to remote dist nodes needs privilege action Key: ISPN-4817 URL: https://issues.jboss.org/browse/ISPN-4817 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 7.0.0.CR1 Reporter: William Burns Assignee: Dan Berindei Priority: Critical Fix For: 7.0.0.CR2 The ClusterListenerReplicateCallable needs to add the listener in a privileged block so that it can work properly. I was also thinking if we need to change all of our messages to send along the current Subject so it can be properly applied to remote invocations as well. In this case we wouldn't need to wrap the listener invocation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4816) HotRod server should handle remote IllegalLifecycleExceptions

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4816: ---------------------------------- Summary: HotRod server should handle remote IllegalLifecycleExceptions Key: ISPN-4816 URL: https://issues.jboss.org/browse/ISPN-4816 Project: Infinispan Issue Type: Bug Components: Remote Protocols, Server Affects Versions: 7.0.0.CR1 Reporter: Dan Berindei Assignee: Galder Zamarreño Priority: Blocker Fix For: 7.0.0.CR2 The ISPN-4717 fix added special handling for {{IllegalLifecycleStateException}}. However, it doesn't handle an {{IllegalLifecycleStateException}} that is wrapped in a {{RemoteException}}, e.g. because a backup owner is shutting down. This caused a failure in DistTopologyChangeUnderLoadTest on my machine: {noformat} 22:05:11,412 ERROR (testng-DistTopologyChangeUnderLoadTest:) [UnitTestTestNGListener] Test testPutsSucceedWhileTopologyChanges(org.infinispan.client.hotrod.DistTopologyChangeUnderLoadTest) failed. java.util.concurrent.ExecutionException: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2478] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistTopologyChangeUnderLoadTest-NodeB-51624, see cause for remote stack trace at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.infinispan.client.hotrod.DistTopologyChangeUnderLoadTest.testPutsSucceedWhileTopologyChanges(DistTopologyChangeUnderLoadTest.java:58) {noformat} Stack trace from the server: {noformat} 22:05:11,314 DEBUG (HotRodServerWorker-150-1:) [HotRodDecoder] Exception caughtio.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistTopologyChangeUnderLoadTest-NodeB-51624, see cause for remote stack trace at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149) at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) at java.lang.Thread.run(Thread.java:745) Caused by: org.infinispan.server.hotrod.HotRodException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistTopologyChangeUnderLoadTest-NodeB-51624, see cause for remote stack trace at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:213) at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:77) at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61) at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) ... 12 more Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistTopologyChangeUnderLoadTest-NodeB-51624, see cause for remote stack trace at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:381) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:536) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290) at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:255) at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:376) at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464) at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:177) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:48) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:172) at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:95) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1492) at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:970) at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:962) at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:485) at org.infinispan.server.core.AbstractProtocolDecoder.put(AbstractProtocolDecoder.scala:252) at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeValue(AbstractProtocolDecoder.scala:207) at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:73) ... 14 more Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:91) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:96) at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:51) at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:185) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ... 1 more {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3720) JMX operation to suppress state transfer failing on all platforms (OutdatedTopologyException)

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3720?page=com.atlassian.jira.plugin.... ] Roman Macor updated ISPN-3720: ------------------------------ Environment: All platforms (was: Failing on Windows 2008 R2 and Windows 2012, both Oracle JDK 6+7. These tests are passing on RHELs and Solaris.) > JMX operation to suppress state transfer failing on all platforms (OutdatedTopologyException) > ----------------------------------------------------------------------------------------------- > > Key: ISPN-3720 > URL: https://issues.jboss.org/browse/ISPN-3720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.CR1, 7.0.0.CR1 > Environment: All platforms > Reporter: Tomas Sykora > Assignee: Mircea Markus > > Please, see linked bugzilla where are attached log/error files. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 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 October 2014