August 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1886) DistributedExecutorService not working with non distributed cache

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1886: -------------------------------------- Summary: DistributedExecutorService not working with non distributed cache Key: ISPN-1886 URL: https://issues.jboss.org/browse/ISPN-1886 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.1.FINAL Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic Fix For: 5.1.2.CR1, 5.1.2.FINAL 1) using DistributedExecutorService::submit with non <distributable-cache> results in NPE protected <K> Map<Address, List<K>> mapKeysToNodes(K... input) { DistributionManager dm = cache.getDistributionManager(); Map<Address, List<K>> addressToKey = new HashMap<Address, List<K>>(input.length * 2); for (K key : input) { Address ownerOfKey = dm.getPrimaryLocation(key); // <------- dm is null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
5
0 / 0

[JBoss JIRA] (ISPN-1984) DistributedExecutorService#submitEverywhere fails in REPL_SYNC mode

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-1984: ----------------------------------------- Summary: DistributedExecutorService#submitEverywhere fails in REPL_SYNC mode Key: ISPN-1984 URL: https://issues.jboss.org/browse/ISPN-1984 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.2.FINAL, 5.1.1.FINAL, 5.1.0.FINAL Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.2.0.FINAL DistributedExecutorService#submitEverywhere fails in REPL_SYNC mode while it works in DIST_SYNC. For some reason the response from the node submitting the task itself is always null therefore throwing exception to caller thread of DistributedExecutorService#submitEverywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
4
0 / 0

[JBoss JIRA] (ISPN-1974) Add <T> Future<T> submit(Address target, Callable<T> task) at least to DefaultExecutorService

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-1974: ---------------------------------- Summary: Add <T> Future<T> submit(Address target, Callable<T> task) at least to DefaultExecutorService Key: ISPN-1974 URL: https://issues.jboss.org/browse/ISPN-1974 Project: Infinispan Issue Type: Enhancement Components: Core API Affects Versions: 5.1.3.FINAL Reporter: Thomas Fromm Assignee: Manik Surtani To easy execute tasks on specific nodes I'd like to have an additional method at DefaultExecutorService: {code} public <T> Future<T> submit(Address target, Callable<T> task){ if (task == null) throw new NullPointerException(); if (target == null) throw new NullPointerException(); List<Address> members = rpc.getTransport().getMembers(); if(!members.contains(target)){ throw new IllegalArgumentException("Unknown node "+target.toString()); } Address me = rpc.getAddress(); DistributedExecuteCommand<T> c = null; if(target.equals(me)){ c = factory.buildDistributedExecuteCommand(clone(task), me, null); } else { c = factory.buildDistributedExecuteCommand(task, me, null); } DistributedRunnableFuture<T> f = new DistributedRunnableFuture<T>(c); executeFuture(target, f); return f; } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
4
0 / 0

[JBoss JIRA] (ISPN-2039) Iteration in DistributedTaskLifecycleService using ServiceLoader fails

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-2039: ----------------------------------------- Summary: Iteration in DistributedTaskLifecycleService using ServiceLoader fails Key: ISPN-2039 URL: https://issues.jboss.org/browse/ISPN-2039 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.4.FINAL Environment: This problem has been observed in AS 7 environment rather than Infinispan standalone Reporter: Ales Justin Assignee: Vladimir Blagojevic Priority: Minor Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL For some unknown reason iteration over available DistributedTaskLifecycle services in DistributedTaskLifecycleService fails, and it fails only in AS environment: Caused by: java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:350) [classes.jar:1.6.0_31] at java.util.Collections$1.nextElement(Collections.java:3389) [classes.jar:1.6.0_31] at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:332) [classes.jar:1.6.0_31] at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:415) [classes.jar:1.6.0_31] at org.infinispan.distexec.spi.DistributedTaskLifecycleService.onPreExecute(DistributedTaskLifecycleService.java:50) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] public <T> void onPreExecute(Callable<T> task) { try { Iterator<DistributedTaskLifecycle> i = loader.iterator(); while (i.hasNext()) { // <------------------------------------------------- we CHECK before DistributedTaskLifecycle cl = i.next(); cl.onPreExecute(task); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
4
0 / 0

[JBoss JIRA] (ISPN-2037) Map/Reduce tasks should process entries in the CacheLoader as well

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2037: ------------------------------------- Summary: Map/Reduce tasks should process entries in the CacheLoader as well Key: ISPN-2037 URL: https://issues.jboss.org/browse/ISPN-2037 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Vladimir Blagojevic Fix For: 5.2.0.FINAL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
9
0 / 0

[JBoss JIRA] (ISPN-2116) Map/Reduce should execute Reduce phase distributively

by Vladimir Blagojevic (JIRA)

11 years, 8 months

3
5
0 / 0

[JBoss JIRA] (ISPN-2179) Incompatible licensed GPL library org.rhq.helpers:rhq-pluginAnnotations used as a dependency

by Sergiu Dumitriu (JIRA)

Sergiu Dumitriu created ISPN-2179: ------------------------------------- Summary: Incompatible licensed GPL library org.rhq.helpers:rhq-pluginAnnotations used as a dependency Key: ISPN-2179 URL: https://issues.jboss.org/browse/ISPN-2179 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.5.FINAL Reporter: Sergiu Dumitriu Assignee: Manik Surtani The RHQ project is licensed under the GPL 2.0, which means that any project that uses RHQ libraries becomes GPL. Not only does this contradict Infinispan's license, but it's also a hidden dependency on a GPL library that makes any other project that thinks it's only using LGPL-compatible libraries actually a GPL project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

6
10
0 / 0

[JBoss JIRA] Created: (ISPN-387) Enable accessing Hot Rod servers via WebSockets

by Galder Zamarreno (JIRA)

Enable accessing Hot Rod servers via WebSockets ----------------------------------------------- Key: ISPN-387 URL: https://jira.jboss.org/jira/browse/ISPN-387 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.1.0.BETA1, 5.1.0.Final Add a flag to Hot Rod server configuration so that appropiate Base64 encoder/decoder can be used when interfacing with WebSocket clients. This might also require for Netty WebSocket channel handlers to be set up so that WebSocket upgrade handshaking can be dealt with independent of Hot Rod. -- 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

11 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-78) Large object support

by Manik Surtani (JIRA)

Large object support -------------------- Key: ISPN-78 URL: https://jira.jboss.org/jira/browse/ISPN-78 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.GA if each VM is allocated a 2GB heap and you have a 100 nodes in a grid with 1 redundant copy for each key, you have a theoretical addressable heap of 100GB. But you are limited by (half) the heap of a single VM per entry, since entries are stored whole. E.g., cache.put(k, my2GBObject) will fail since you need at least 2GB for the object + another 2GB for its serialized form. This gets worse when you try cache.put(k, my10GBObject). This *should* be possible if we have a theoretical 100GB heap. Potential solutions here are to fragment large objects, and store each fragment under separate keys. Another approach would be to directly stream objects to disk. etc. Needs thought and design, possibly a separate API to prevent 'pollution" of the more simplistic API. (JumboCache?) Re: fragmenting, issues to overcome: How many chunks to fragment into? Max size of each key could be configured, but how do we determine the size of an Object? VM instrumentation? Or perhaps the JumboCache only stores byte[]'s? -- 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

11 years, 8 months

10
32
0 / 0

[JBoss JIRA] (ISPN-1865) Update indexes only when needed

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1865: -------------------------------------- Summary: Update indexes only when needed Key: ISPN-1865 URL: https://issues.jboss.org/browse/ISPN-1865 Project: Infinispan Issue Type: Enhancement Components: Querying Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Sanne Grinovero // put in cache a value with 2 field, one indexed and one not indexed. Value value = new Value(); value.setNonIndexedFieldValue(123); value.setIndexedFieldValue(456); cache.put("key", value); // later... // get back value from cache and update the not indexed field Value value = cache.get("key"); value.setNonIndexedFieldValue(789); cache.put("key", value); The second put operation will trigger index to update even tough it hasn't changed. Sanne suggested : " Thinking about it, there might be some situations in which we can detect it, for example if the put is going to carry a valid return value then we could compare values in string form.. nice, please open an improvement request on JIRA!" See https://community.jboss.org/thread/195303 for complete reference -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2012