January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4778) PessimisticLockingInterceptor throws when handling remote clear command

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4778?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4778: ------------------------------------- Assignee: (was: Mircea Markus) > PessimisticLockingInterceptor throws when handling remote clear command > ----------------------------------------------------------------------- > > Key: ISPN-4778 > URL: https://issues.jboss.org/browse/ISPN-4778 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: JBoss WildFly 8.1.0.FINAL > Reporter: Arjan t > Labels: remote > > Using InfiniSpan as it's shipped with Jboss WildFly 8.1.0.Final as distributed cache for Hibernate, it appears that the ClearCommand does not work in a cluster when *pessimistic locking* is used. Pessimistic locking seems to be the default in WildFly, even when theoretically it shouldn't be. > This will result in the following exception: > {noformat} > java.lang.ClassCastException: org.infinispan.context.impl.NonTxInvocationContext cannot be cast to org.infinispan.context.impl.TxInvocationContext > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitClearCommand(PessimisticLockingInterceptor.java:194) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38) > 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.visitClearCommand(AbstractVisitor.java:47) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255) > at org.infinispan.interceptors.TxInterceptor.visitClearCommand(TxInterceptor.java:206) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38) > 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.visitClearCommand(AbstractVisitor.java:47) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38) > 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:95) > at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50) > at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {noformat} > The incoming command looks as follows: > {noformat} > CacheRpcCommand cmd: > command: > ClearCommand{flags=null} > icf: > org.infinispan.context.TransactionalInvocationContextFactory@3ef1861e > Interceptor chain: > > >> org.infinispan.interceptors.InvocationContextInterceptor -- checks if stopping, otherwise continues > >> org.infinispan.interceptors.CacheMgmtInterceptor -- does nothing > >> org.infinispan.interceptors.TxInterceptor -- checks "shouldEnlist", if false does nothing > >> org.infinispan.interceptors.NotificationInterceptor -- does nothing > >> org.infinispan.interceptors.locking.PessimisticLockingInterceptor -- Throws exception if something in cache > >> org.infinispan.interceptors.EntryWrappingInterceptor > >> org.infinispan.interceptors.InvalidationInterceptor > >> org.infinispan.interceptors.CallInterceptor > {noformat} > The problem seems to be that {{org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand}} always creates a {{NonTxInvocationContext}}. As per the following line of code: > {code} > final InvocationContext ctx = icf.createRemoteInvocationContextForCommand(vc, getOrigin()); > {code} > When handling the ClearCommand, the PessimisticLockInterceptor always casts this to a {{TxInvocationContext}} whenever {{dataContainer}} is not empty, e.g. when there is cached data on the node where the clear command arrives. This happens in the following code: > {code} > public Object visitClearCommand(InvocationContext ctx, ClearCommand command) throws Throwable { > try { > boolean skipLocking = hasSkipLocking(command); > long lockTimeout = getLockAcquisitionTimeout(command, skipLocking); > for (InternalCacheEntry entry : dataContainer.entrySet()) > lockAndRegisterBackupLock((TxInvocationContext) ctx, entry.getKey(), lockTimeout, skipLocking); > return invokeNextInterceptor(ctx, command); > } catch (Throwable te) { > releaseLocksOnFailureBeforePrepare(ctx); > throw te; > } > } > {code} > So seemingly this can't ever work. > Either the {{PessimisticLockingInterceptor}} can't be in a the interceptor chain when handling commands from a remote destination, or something has to be done about about the {{InvocationContext}} when handling remote commands? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3512) Don't deserialize the cache loader entries needed by a remote node

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3512?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3512: ------------------------------------- Assignee: (was: Mircea Markus) > Don't deserialize the cache loader entries needed by a remote node > ------------------------------------------------------------------- > > Key: ISPN-3512 > URL: https://issues.jboss.org/browse/ISPN-3512 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > > the new API allows exposing the stored entries in serialized format. If an entry is fetched from persistent storage for the sole purpose of being sent remotely, we no longer need to deserialize it (when reading from the store) and serialize it back (when writing to the wire). Now we can write to the wire the serialized format as read fro the storage directly -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4015) Infinispan initialization failed with Jboss 5.1.2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4015?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4015: ------------------------------------- Assignee: (was: Mircea Markus) > Infinispan initialization failed with Jboss 5.1.2 > -------------------------------------------------- > > Key: ISPN-4015 > URL: https://issues.jboss.org/browse/ISPN-4015 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Final > Environment: Linux with Jboss 5.1.2 as Application Server > Reporter: suryanarayana s > > Initialization of Infinispan with Jboss 5.1.2 failed to load the application. If we remove inifinispan jars then application startus up without any issue. We gone through some workarounds and fixed the issue with Jboss AS 5.1.0 & 5.1.0 GA, same is not working for jboss version 5.1.2. > This has been an iterative approach from our end to fix Infinispan config (jars) for every version of JBoss Application Server. Please suggest some permanent solution for this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4726) Compatibility mode: modules

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4726?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4726: ------------------------------------- Assignee: (was: Mircea Markus) > Compatibility mode: modules > --------------------------- > > Key: ISPN-4726 > URL: https://issues.jboss.org/browse/ISPN-4726 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Servers > Affects Versions: 7.0.0.Beta1 > Reporter: Radim Vansa > > I've tried to run the server in compatibility mode, but haven't included the JAR with class uploaded by HotRod client - and boom, I got ClassNotFoundExceptions. > To resolve this, I've modified modules.xml for infinispan-commons and added the JAR with my classes there, but I don't think this is a correct solution - nor creating a new module and adding this as dependency to infinispan-commons. IMO I am using Infinispan as service, therefore, I should not put application classes as dependencies into modules. > The recommended approach is not described neither in User Guide nor Server Guide - these specify just the configuration option. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1947) Automate staging repository step in release script

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1947?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-1947: ------------------------------------- Assignee: (was: Mircea Markus) > Automate staging repository step in release script > -------------------------------------------------- > > Key: ISPN-1947 > URL: https://issues.jboss.org/browse/ISPN-1947 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Sanne Grinovero > Priority: Optional > > The following plugin can be used to control the staging repository from command line (including authenticating with your account as set in your settings file) > {code:xml} > <plugin> > <groupId>org.sonatype.plugins</groupId> > <artifactId>nexus-maven-plugin</artifactId> > <configuration> > <nexusUrl>https://repository.jboss.org/nexus</nexusUrl> > <automatic>true</automatic> > </configuration> > </plugin> > {code} > Goals are described at: https://repository.sonatype.org/content/sites/maven-sites/nexus-maven-plu... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4268) If user sets a cache store using JON console, the cache store does not start without restarting a server instance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4268?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4268: ------------------------------------- Assignee: (was: Mircea Markus) > If user sets a cache store using JON console, the cache store does not start without restarting a server instance > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4268 > URL: https://issues.jboss.org/browse/ISPN-4268 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Reporter: Suzumura Keishi > Labels: 621 > > If user sets a cache store using JON console, the cache store does not start without restarting a server instance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3112) KeyAffinityService API - provide overload of getKeyForAddress()

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3112?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3112: ------------------------------------- Assignee: (was: Mircea Markus) > KeyAffinityService API - provide overload of getKeyForAddress() > --------------------------------------------------------------- > > Key: ISPN-3112 > URL: https://issues.jboss.org/browse/ISPN-3112 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.3.0.Beta1 > Reporter: Ben Cotton > Priority: Minor > > Add to the org.inifinispan.affinity.KeyAffinityService<K> interface an overload = > *K getKeyForAddress(Address address, K otherKey);* > //compute address specific version of 'otherKey' -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3647) GridFileSystem data becomes corrupted if file-store evication is enabled.

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3647?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3647: ------------------------------------- Assignee: (was: Mircea Markus) > GridFileSystem data becomes corrupted if file-store evication is enabled. > ------------------------------------------------------------------------- > > Key: ISPN-3647 > URL: https://issues.jboss.org/browse/ISPN-3647 > Project: Infinispan > Issue Type: Bug > Components: Core, Eviction > Affects Versions: 5.2.6.Final > Reporter: Lincoln Baxter III > > I don't know if this is still an issue or not in the 6.x branch, but this is occurring when using the Infinispan 5.2.6 provided with EAP6.1.1 (Yes, yes, I know you should not use the provided infinispan, but it's the easiest way to get it clustered on openshift.) > This is my configuration: > {code} > <cache-container name="redoculous" aliases="ha-partition" default-cache="default" jndi-name="java:jboss/infinispan/redoculous-cluster"> > <transport/> > <replicated-cache name="filesystem.metadata" mode="SYNC" start="LAZY"> > <locking isolation="REPEATABLE_READ"/> > <eviction strategy="LIRS" max-entries="1000"/> > <file-store path="redoculous" preload="true" passivation="true"/> > </replicated-cache> > <distributed-cache name="filesystem.content" owners="2" mode="SYNC" start="LAZY"> > <locking isolation="REPEATABLE_READ"/> > <eviction strategy="LIRS" max-entries="10000"/> > <file-store path="redoculous" preload="true" passivation="true"/> > </distributed-cache> > </cache-container> > {code} > This is revealed particularly when pushing zip files to the grid. After retrieving them, upon attempt to decompress the file, ZipEntry will typically throw Exceptions about invalid entry header information, and various other sporadic issues. > I believe this is an eviction issue because typically the first few files work, but things begin to fail more and more, the more files are placed into the grid filesystem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3914) Add support for Group Listeners

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3914?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3914: ------------------------------------- Assignee: (was: Mircea Markus) > Add support for Group Listeners > ------------------------------- > > Key: ISPN-3914 > URL: https://issues.jboss.org/browse/ISPN-3914 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 6.0.1.Final > Reporter: D K > Labels: listeners > > Allow Group Listeners that could handle events based on the @Group annotation within the POJO. > A single thread from a Group Listener thread pool would handle events for a specific Group within the node. > The Group Listener thread would need to lock the POJOs within the specific Group it is currently working on and prevent other Group Listener threads from accessing POJOs within that group. > POJOs within a Group should be handled in FIFO order -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4052) Quickstart distribution example does not work with xml configuration

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4052?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4052: ------------------------------------- Assignee: (was: Mircea Markus) > Quickstart distribution example does not work with xml configuration > -------------------------------------------------------------------- > > Key: ISPN-4052 > URL: https://issues.jboss.org/browse/ISPN-4052 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Anton Lisovenko > > org.infinispan.quickstart.clusteredcache.distribution.AbstractNode has the block > this.cacheManager = createCacheManagerProgramatically(); > // Uncomment to create cache from XML > /*try { > this.cacheManager = createCacheManagerFromXml(); > } catch (IOException e) { > throw new RuntimeException(e); > }*/ > When I uncomment the xml configuration and run Node0, I recieve the error: > {quote} > Exception in thread "main" org.infinispan.commons.CacheConfigurationException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[29,4] > Message: found: CHARACTERS, expected START_ELEMENT or END_ELEMENT > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:102) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:251) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:224) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:211) > at org.infinispan.quickstart.clusteredcache.distribution.AbstractNode.createCacheManagerFromXml(AbstractNode.java:51) > at org.infinispan.quickstart.clusteredcache.distribution.AbstractNode.<init>(AbstractNode.java:62) > at org.infinispan.quickstart.clusteredcache.distribution.Node0.<init>(Node0.java:28) > at org.infinispan.quickstart.clusteredcache.distribution.Node0.main(Node0.java:31) > 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:601) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[29,4] > Message: found: CHARACTERS, expected START_ELEMENT or END_ELEMENT > at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.nextTag(XMLStreamReaderImpl.java:1250) > at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.nextTag(XMLExtendedStreamReaderImpl.java:88) > at org.infinispan.configuration.parsing.Parser60.readElement(Parser60.java:64) > at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:141) > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:123) > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:110) > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:97) > ... 12 more > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015