November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3688) Add Hot Rod protocol version 1.3 description in user guide

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3688?page=com.atlassian.jira.plugin.... ] Work on ISPN-3688 started by Adrian Nistor. > Add Hot Rod protocol version 1.3 description in user guide > ---------------------------------------------------------- > > Key: ISPN-3688 > URL: https://issues.jboss.org/browse/ISPN-3688 > Project: Infinispan > Issue Type: Task > Components: Documentation, Remote protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2, 6.0.0.Final > > -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3615) Add user documentation for the remote query modules

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3615?page=com.atlassian.jira.plugin.... ] Work on ISPN-3615 started by Adrian Nistor. > Add user documentation for the remote query modules > --------------------------------------------------- > > Key: ISPN-3615 > URL: https://issues.jboss.org/browse/ISPN-3615 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3651) Allow @Listener classes to be non-public

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3651?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3651: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow @Listener classes to be non-public > ---------------------------------------- > > Key: ISPN-3651 > URL: https://issues.jboss.org/browse/ISPN-3651 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Affects Versions: 6.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Currently the listener class is forced to be public. We should remove this check and accept any visibility and make the listener method accessible if needed. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2143) Improve how different indexed caches sync up on new indexed types

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2143?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2143: ---------------------------------- Fix Version/s: 6.0.0.CR2 > Improve how different indexed caches sync up on new indexed types > ----------------------------------------------------------------- > > Key: ISPN-2143 > URL: https://issues.jboss.org/browse/ISPN-2143 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Blocker > Labels: stable_embedded_query > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Currently when a node receives an unknown type, it doesn't inform all other nodes, which might fail to get metadata and index boot information from it. > Also, the list of known types should be stored somewhere. > When a shared index is used, we might be able to load some type names from the index itself, but unfortunately usually we need the type name to initialize the index. Rely on an index storage convention? > See also comments in {{org.infinispan.query.indexmanager.IndexUpdateCommand}} -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2143) Improve how different indexed caches sync up on new indexed types

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2143?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2143: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Improve how different indexed caches sync up on new indexed types > ----------------------------------------------------------------- > > Key: ISPN-2143 > URL: https://issues.jboss.org/browse/ISPN-2143 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Priority: Blocker > Labels: stable_embedded_query > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Currently when a node receives an unknown type, it doesn't inform all other nodes, which might fail to get metadata and index boot information from it. > Also, the list of known types should be stored somewhere. > When a shared index is used, we might be able to load some type names from the index itself, but unfortunately usually we need the type name to initialize the index. Rely on an index storage convention? > See also comments in {{org.infinispan.query.indexmanager.IndexUpdateCommand}} -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3597) ClusterRegistry should provide event notifications

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3597?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3597: ---------------------------------- Fix Version/s: 6.0.0.CR2 > ClusterRegistry should provide event notifications > -------------------------------------------------- > > Key: ISPN-3597 > URL: https://issues.jboss.org/browse/ISPN-3597 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 6.0.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Add scoped listeners. Use the existing listener mechanism. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3597) ClusterRegistry should provide event notifications

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3597?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3597: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ClusterRegistry should provide event notifications > -------------------------------------------------- > > Key: ISPN-3597 > URL: https://issues.jboss.org/browse/ISPN-3597 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 6.0.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Add scoped listeners. Use the existing listener mechanism. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2475: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2198 > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {quote} -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3556: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2197 > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3685?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3685: -------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3685 > URL: https://issues.jboss.org/browse/ISPN-3685 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.CR1 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster: > java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException > at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775) > at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) > at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732) > at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) > at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732) > at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72) > at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766) > ... 4 more > This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific. -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013