November 2010 - infinispan-issues

[JBoss JIRA] Created: (ISPN-735) Bug in the cache event notifications {CacheStarted, CacheStopped, ViewChanged}

by Thomas Fuller (JIRA)

Bug in the cache event notifications {CacheStarted, CacheStopped, ViewChanged} ------------------------------------------------------------------------------ Key: ISPN-735 URL: https://jira.jboss.org/browse/ISPN-735 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 4.1.0.Final Reporter: Thomas Fuller Assignee: Manik Surtani I am currently working on adding some functionality to the Grails Infinispan Plugin, which relies on Infinispan-4.1.0.FINAL (Radegast). This particular functionality is expressed as a mixin and will allow the developer to use a closure to receive event notifications from the cache -- for example: agentCache.onCacheEntryLoaded { log.info ("=====> Cache entry loaded: $it") } I have a basic unit test for each of the events detailed in the Listener documentation here: http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/notifications... however the following three annotations are not being registered (whereas all the others are): import org.infinispan.notifications.cachemanagerlistener.annotation.CacheStarted import org.infinispan.notifications.cachemanagerlistener.annotation.CacheStopped import org.infinispan.notifications.cachemanagerlistener.annotation.ViewChanged Instead I'm receiving a message like the following when my test application starts: cachelistener.CacheNotifierImpl Attempted to register listener of class class com.coherentlogic.grails.infinispan.listeners.CacheStoppedListener, but no valid,public methods annotated with method-level event annotations found! Ignoring listener. and likewise my unit tests are also failing. Here's an example of one of the listener implementations which works: @Listener class CacheEntryCreatedListener { private def closure @CacheEntryCreated public void cacheEntryCreated (cacheEntryCreatedEvent) { closure?.call (cacheEntryCreatedEvent) } } Here's an example of one of the listener implementations which does not work: @Listener class CacheStoppedListener { private def closure @CacheStopped public void cacheStopped (cacheStoppedEvent) { closure?.call (cacheStoppedEvent) } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-715) Eager locking a single node should only acquire a single lock

by Erik Salter (JIRA)

Eager locking a single node should only acquire a single lock ------------------------------------------------------------- Key: ISPN-715 URL: https://jira.jboss.org/browse/ISPN-715 Project: Infinispan Issue Type: Feature Request Reporter: Erik Salter Assignee: Manik Surtani The new eager/explicit lock for a single node feature in 4.2.0 can be further optimized. Right now, a local lock and a lock on the node where the key is hashed is acquired. To increase throughput and minimize deadlock occurrences, we should only acquire the one lock (on the node). (Obviously, if the key is hashed to the local node, the local lock and the node lock are one in the same). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-352) Add per-cache coordinator.

by Alexander Gavrilov (JIRA)

Add per-cache coordinator. -------------------------- Key: ISPN-352 URL: https://jira.jboss.org/jira/browse/ISPN-352 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Alexander Gavrilov Assignee: Manik Surtani We trying to use Infinispan for our cluster. We have two types of nodes in cluster. "Type 1" nodes use all set of caches defined in system, but "Type 2" nodes uses only small subset of nodes. For each cache on each node we have job, that fetch data from external store and put that data in the cache. We need this job to be executed only in one node from whole cluster and is natural to test if node is cache coordinator and execute job only if it is. In current implementation it's possible to determinate only cluster coordinator. But when node of "Type 2" becomes coordinator it is impossible to update some caches, because they are not defined in this node. It would be fine to declare not only oldest node in cluster as cluster coordinator but oldest node containing cache as this concrete cache coordinator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-781) Memcached pipelined delete messages wrongly processed

by Galder Zamarreño (JIRA)

Memcached pipelined delete messages wrongly processed ----------------------------------------------------- Key: ISPN-781 URL: https://jira.jboss.org/browse/ISPN-781 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.0.BETA1, 4.1.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.0.CR1, 4.2.0.Final The code incorrectly detects the optional, unsupported, noreply parameter. >From Michal: "The text protocol processing logic regarding delete command doesn't allow for command pipelining: $ echo -e "delete a\r\ndelete a\r" | nc localhost 11211 CLIENT_ERROR org.infinispan.server.core.ServerException: java.io.StreamCorruptedException: Unable to parse noreply optional argument the logic is as follows 1. read header "delete " 2. read key "a\r\n" 3. read parameters READS ERRONEOUSLY NEXT COMMAND: "delete a\r\n" when sending one command only this is ok $ echo -e "delete a\r" | nc localhost 11211 NOT_FOUND because read parameters in step 3 just returns line "" but makes trouble when delete command appears in the middle of the command input stream." -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-778) Memcached server module stat "reclaimed" missing

by Galder Zamarreño (JIRA)

Memcached server module stat "reclaimed" missing ------------------------------------------------ Key: ISPN-778 URL: https://jira.jboss.org/browse/ISPN-778 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.0.BETA1, 4.1.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 4.2.0.CR1, 4.2.0.Final There's a new stat in memcached protocol [1] called "reclaimed" that is not yet implemented, nor mentioned in the Wiki [2] [1] https://github.com/memcached/memcached/blob/master/doc/protocol.txt [2] http://community.jboss.org/wiki/UsingInfinispanMemcachedServe -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-787) Cache.get(...) does not go remote if DIST + batch + REPEATABLE_READ

by Paul Ferraro (JIRA)

Cache.get(...) does not go remote if DIST + batch + REPEATABLE_READ ------------------------------------------------------------------- Key: ISPN-787 URL: https://jira.jboss.org/browse/ISPN-787 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.0.BETA1 Reporter: Paul Ferraro Assignee: Manik Surtani Priority: Critical Attachments: ISPN787TestCase.java The attached test reproduces the problem. * Create 3 caches from 3 clustered managers * Do a cache put * If batching is enabled, and isolation level is REPEATABLE_READ, cache get only returns the correct value for those nodes to which the key hashes * The same cache get succeeds if isolation level is dropped to READ_COMMITTED or if get is not done within a batch -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-780) Memcached key limit not working with get/gets commands

by Galder Zamarreño (JIRA)

Memcached key limit not working with get/gets commands ------------------------------------------------------ Key: ISPN-780 URL: https://jira.jboss.org/browse/ISPN-780 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.0.BETA1, 4.1.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.0.CR1 >From Michal: "Tried with infinispan 4.2.0.BETA1 and the limitation still doesn't work with commands get and gets (the case is not handled in the method MemcachedDecoder.readKeys)" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-723) slow puts on async JdbmCacheStore

by Michael Brackx (JIRA)

slow puts on async JdbmCacheStore --------------------------------- Key: ISPN-723 URL: https://jira.jboss.org/browse/ISPN-723 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.1.0.Final Reporter: Michael Brackx Assignee: Manik Surtani Puts on a cache with an async JdbmCacheStore are much slower than on a cache with an async FileCacheStore. If the cache store does not yet exists, it is as fast as a FileCacheStore. If it already exists, it is about 10 times slower. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-774) Nonexistent memcached command should result in ERROR response, not SERVER_ERROR

by Galder Zamarreño (JIRA)

Nonexistent memcached command should result in ERROR response, not SERVER_ERROR ------------------------------------------------------------------------------- Key: ISPN-774 URL: https://jira.jboss.org/browse/ISPN-774 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.0.BETA1, 4.1.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.0.CR1, 4.2.0.Final >From Michal: "according to the memcached text protocol: https://github.com/memcached/memcached/blob/master/doc/protocol.txt sending of an unknown command should result in response "ERROR\r\n" instead we are sending SERVER_ERROR. echo -e "blah\r" | nc localhost 11211 SERVER_ERROR org.infinispan.server.core.UnknownOperationException: Unknown operation: blah" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-772) Thread local storage keeping reference to an org.infinispan.context.impl.LocalTxInvocationContext

by Scott Marlow (JIRA)

Thread local storage keeping reference to an org.infinispan.context.impl.LocalTxInvocationContext -------------------------------------------------------------------------------------------------- Key: ISPN-772 URL: https://jira.jboss.org/browse/ISPN-772 Project: Infinispan Issue Type: Bug Reporter: Scott Marlow Assignee: Manik Surtani I'm seeing the following sequence of invocations during AS cluster classloader leak unit tests: 1. InvocationContextContainerImpl.createInvocationContext creates a new LocalTxInvocationContext (lets call it #3011) and sets thread local (icTL) to it. 2. InvocationContextContainerImpl.suspend() LocalTxInvocationContext #3011 which clears the thread local reference. 3. We InvocationContextContainerImpl.resume() LocalTxInvocationContext #3011 which sets the thread local reference. 4. We InvocationContextContainerImpl.suspend() LocalTxInvocationContext #3011 which clears the thread local reference. 5. We InvocationContextContainerImpl.resume() LocalTxInvocationContext #3011 which sets the thread local reference. I don't see another suspend call, so LocalTxInvocationContext #3011 is still referenced by the thread local InvocationContextContainerImpl.icTL which keeps the classloader in memory (the icTL reference is the only reference to the classloader). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2010