June 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-312) Ability to group data entries

by Mindaugas Žakšauskas (JIRA)

Ability to group data entries ----------------------------- Key: ISPN-312 URL: https://jira.jboss.org/jira/browse/ISPN-312 Project: Infinispan Issue Type: Feature Request Components: Core API, Distributed Cache, Eviction, Locking and Concurrency Affects Versions: 4.0.0.CR2 Reporter: Mindaugas Žakšauskas Assignee: Manik Surtani Priority: Minor This is a spin-off from http://lists.jboss.org/pipermail/infinispan-dev/2009-December/001968.html. The requested feature would allow distinct entries to be assigned to custom arbitrary groups. Later in time those groups could be flushed on demand without any knowledge of entry keys. This feature exists in other open source cache library, see: http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/base/Cac... -- 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

12 years, 9 months

7
15
0 / 0

[JBoss JIRA] Created: (ISPN-1199) RemoteCacheManager failure in multi-threaded environment with maxActive=Integer.MAX_VALUE

by Michal Linhard (JIRA)

RemoteCacheManager failure in multi-threaded environment with maxActive=Integer.MAX_VALUE ----------------------------------------------------------------------------------------- Key: ISPN-1199 URL: https://issues.jboss.org/browse/ISPN-1199 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR5 Reporter: Michal Linhard Assignee: Manik Surtani I get erros like these, when I run test with 100 threads using either shared or multiple remote cache managers: {code} java.lang.IllegalStateException: We should not reach here! at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:73) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:201) at org.infinispan.CacheSupport.put(CacheSupport.java:51) at org.jboss.edg.test.MultiThreadedManualTest$Runner.run(MultiThreadedManualTest.java:77) {code} The cause in my environment came to connection-pool configuration property "maxActive" clients set to Integer.MAX_VALUE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1158) passivation without eviction warning

by Michal Linhard (JIRA)

passivation without eviction warning ------------------------------------ Key: ISPN-1158 URL: https://issues.jboss.org/browse/ISPN-1158 Project: Infinispan Issue Type: Feature Request Components: Eviction, Loaders and Stores Affects Versions: 5.0.0.CR4 Reporter: Michal Linhard Assignee: Michal Linhard Priority: Minor Turning of Passivation without eviction doesn't make sense. We should display warning that this is not a good configuration and cache store probably won't get used at all in that case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
15
0 / 0

[JBoss JIRA] Created: (ISPN-1210) TreeCache getData method returns null Map

by Annadurai Narayanan (JIRA)

TreeCache getData method returns null Map ----------------------------------------- Key: ISPN-1210 URL: https://issues.jboss.org/browse/ISPN-1210 Project: Infinispan Issue Type: Bug Components: Tree API Affects Versions: 5.0.0.CR6 Environment: Windows OS Reporter: Annadurai Narayanan Assignee: Manik Surtani Priority: Blocker TreeCache getData() method returns null instead of mapped value from the node. Please see the unit test case written in junit. public class TreeCacheTest extends Assert { @Test public void testTreeCache() { Configuration c = new Configuration(); c.setInvocationBatchingEnabled(true); TreeCache<Object, Object> cache = new TreeCacheFactory().createTreeCache(new DefaultCacheManager(c).getCache()); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key1","TRADE1"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key2","TRADE2"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key3","TRADE3"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key4","TRADE4"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key5","TRADE5"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key6","TRADE6"); cache.put(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key7","TRADE7"); Object object = cache.get(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE")),"key7"); assertNotNull(object); Map<Object, Object> data = cache.getData(Fqn.fromRelativeFqn(getBase(), Fqn.fromString("TRADE"))); assertNotNull(data); } private Fqn getBase() { return Fqn.fromString("SYSTEMSTATUS"); } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-1000) PUSH based rehashing

by Manik Surtani (JIRA)

PUSH based rehashing -------------------- Key: ISPN-1000 URL: https://issues.jboss.org/browse/ISPN-1000 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.2.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA2, 5.0.0.FINAL Current rehash schemes are based on a PULL of state. Joiners (and new owners after a leave) pull state from their neighbours. This JIRA is to reimplement this as a PUSH based scheme, where all nodes detect new joiners (or leavers) and analyse their internal state and determine what needs to be pushed where. The scheme should be more robust, involving far fewer RPCs and coordination, and would work better for merge views detected when partitions heal. Based on Bela's prototype on https://github.com/belaban/infinispan/tree/rebalance-changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
11
0 / 0

[JBoss JIRA] Created: (ISPN-1155) CommandAwareRpcDispatcher should not swallow exceptions when handling inbound RPC

by Manik Surtani (JIRA)

CommandAwareRpcDispatcher should not swallow exceptions when handling inbound RPC --------------------------------------------------------------------------------- Key: ISPN-1155 URL: https://issues.jboss.org/browse/ISPN-1155 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 5.0.0.CR4 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.CR5 Comment from a user: {quote} The allocation point was an Object deserialization triggered by Infinispan's unmarshalling code, and the OOME was swallowed by org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle() by catching Throwable -- which only logs the Throwable if log.trace is enabled (yuck). {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1193) return code for rest wipe cache command changed

by Michal Linhard (JIRA)

return code for rest wipe cache command changed ----------------------------------------------- Key: ISPN-1193 URL: https://issues.jboss.org/browse/ISPN-1193 Project: Infinispan Issue Type: Feature Request Reporter: Michal Linhard Assignee: Galder Zamarreño let's document a return value of cache wipe operation in REST interface and make it consistent between 5.0 and 4.2. wiping the cache via REST in 5.0.0.CR4 {code} [mlinhard@michal-linhard ~]$ curl -X DELETE -v http://test1:8080/datagrid/rest/___defaultcache * About to connect() to test1 port 8080 (#0) * Trying 192.168.11.101... connected * Connected to test1 (192.168.11.101) port 8080 (#0) > DELETE /datagrid/rest/___defaultcache HTTP/1.1 > User-Agent: curl/7.21.0 (i386-redhat-linux-gnu) libcurl/7.21.0 NSS/3.12.8.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4 > Host: test1:8080 > Accept: */* > < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Content-Length: 0 < Date: Thu, 23 Jun 2011 11:48:01 GMT < * Connection #0 to host test1 left intact * Closing connection #0 {code} wiping the cache via REST in 4.2.2-SNAPSHOT {code} [mlinhard@michal-linhard ~]$ curl -X DELETE -v http://localhost:8080/infinispan-server-rest/rest/___defaultcache * About to connect() to localhost port 8080 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8080 (#0) > DELETE /infinispan-server-rest/rest/___defaultcache HTTP/1.1 > User-Agent: curl/7.21.0 (i386-redhat-linux-gnu) libcurl/7.21.0 NSS/3.12.8.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4 > Host: localhost:8080 > Accept: */* > < HTTP/1.1 204 No Content < Server: Apache-Coyote/1.1 < X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1 < Date: Thu, 23 Jun 2011 11:51:24 GMT < * Connection #0 to host localhost left intact * Closing connection #0 {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-1211) Avoid master relying on a JBoss-WS snapshot

by Galder Zamarreño (JIRA)

Avoid master relying on a JBoss-WS snapshot ------------------------------------------- Key: ISPN-1211 URL: https://issues.jboss.org/browse/ISPN-1211 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR7 Why is master relying on a JBoss-WS snapshot? [INFO] ------------------------------------------------------------------------ [INFO] Building Infinispan Core 5.0.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/ws/jbos... Investigate... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1177) java.lang.IllegalArgumentException attempting to create Logger for HotRod Client

by Jeff Ramsdale (JIRA)

java.lang.IllegalArgumentException attempting to create Logger for HotRod Client -------------------------------------------------------------------------------- Key: ISPN-1177 URL: https://issues.jboss.org/browse/ISPN-1177 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.CR4 Reporter: Jeff Ramsdale Assignee: Manik Surtani Priority: Critical Changes to 5.0.0 (CR4, in my case) related to logging break my app. I use slf4j for logging and route commons-logging, log4j, and java.util.logging to slf4j to route to Logback. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
21
0 / 0

[JBoss JIRA] Created: (ISPN-1096) Rework application class loading to be more friendly to modular environments

by Pete Muir (JIRA)

Rework application class loading to be more friendly to modular environments ---------------------------------------------------------------------------- Key: ISPN-1096 URL: https://issues.jboss.org/browse/ISPN-1096 Project: Infinispan Issue Type: Feature Request Reporter: Pete Muir Assignee: Manik Surtani There are two issues with modularity/classloading in Infinispan: 1) Using the TCCL as the classloader to load Infinispan classes is a bad idea. Instead we should use org.infinispan.foo.Bar.getClass().getClassLoader(). This has been addressed as a separate issue. 2) When we need to load application classes we need a different approach to that used today. Most of the time the TCCL is perfect for this. However *sometimes* Infinispan may be invoked outside of the application, when the TCCL may not be set in AS7. Jason and I discussed three options: a) require (through a platform integration documentation contract) that the TCCL must always be set when Infinispan is invoked. b) Have some sort of InvocationContext which knows what the correct classloader to use is (aka Hibernate/Seam/Weld design where there is a per-application construct based on a ThreadLocal). Given this hasn't been designed into the core, it seems like a large retrofit c) Make users specify the CL (directly or indirectly) via the API (as we discussed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

5
16
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2011