November 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-1402) Limit rate of incoming requests on Hot Rod server

by Sanne Grinovero (JIRA)

Limit rate of incoming requests on Hot Rod server ------------------------------------------------- Key: ISPN-1402 URL: https://issues.jboss.org/browse/ISPN-1402 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.1.0.BETA1 Like application servers have a way to configure a limit of parallel incoming requests, if a too high number of requests is incoming some of these should be put in a queue, to protect the server performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1043) Ensure properly clustered and booted cache node is used for distribtued executors and map reduce

by Vladimir Blagojevic (JIRA)

Ensure properly clustered and booted cache node is used for distribtued executors and map reduce ------------------------------------------------------------------------------------------------ Key: ISPN-1043 URL: https://issues.jboss.org/browse/ISPN-1043 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.0.0.BETA2 We have to ensure that only properly booted and clustered Infinispan cache nodes are used for distributed execution and mapreduce http://community.jboss.org/thread/165231?tstart=0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1041) Ensure Callable isolation as it gets invoked across the cluster

by Vladimir Blagojevic (JIRA)

Ensure Callable isolation as it gets invoked across the cluster --------------------------------------------------------------- Key: ISPN-1041 URL: https://issues.jboss.org/browse/ISPN-1041 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.0.0.CR1 If Callable submitted for distributed execution contains mutable instance fields they might get mutated locally before being sent for a remote execution thus potentially resulting in wrong results being returned to a task invoker. Just before Callable is dispersed across cluster it gets invoked locally where instance fields of a submitted Callable can be possibly mutated; Callable is in turn sent to remote nodes with mutated values instead of "original" field values as submitted by user. We need to ensure that each execution node gets a pristine version of Callable object submitted by the user. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1039) Create DistributedExecutorService and MapReduce examples

by Vladimir Blagojevic (JIRA)

Create DistributedExecutorService and MapReduce examples --------------------------------------------------------- Key: ISPN-1039 URL: https://issues.jboss.org/browse/ISPN-1039 Project: Infinispan Issue Type: Task Components: Demos and Tutorials Affects Versions: 5.0.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.0.0.FINAL Create at least a few examples/use cases for DistributedExecutorService and MapReduceTask. Include these examples into a test suite and include them into getting started wiki page for distributed execution framework. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1274) DefaultExecutorService uses no thread pool when it decides to invokeLocally

by Thomas Peuss (JIRA)

DefaultExecutorService uses no thread pool when it decides to invokeLocally --------------------------------------------------------------------------- Key: ISPN-1274 URL: https://issues.jboss.org/browse/ISPN-1274 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.CR8 Reporter: Thomas Peuss Assignee: Manik Surtani DefaultExecutorService uses no thread pool when it decides to invokeLocally. It always uses the calling thread in this case. This leads to bad concurrency (1). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

7
9
0 / 0

[JBoss JIRA] Created: (ISPN-1129) method o.i.distexec.DefaultExecutorService.invokeAny(Collection tasks) never returns

by Mikhail Khludnev (JIRA)

method o.i.distexec.DefaultExecutorService.invokeAny(Collection tasks) never returns ------------------------------------------------------------------------------------ Key: ISPN-1129 URL: https://issues.jboss.org/browse/ISPN-1129 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.CR3 Reporter: Mikhail Khludnev Assignee: Manik Surtani DefaultExecutorService.invokeAny() seems not working ever just because DistributedExecutionCompletionService seems not working too, because it never attach it's listener to tasks. I made a test, but didn't find an easy approach to fix it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1294) Run local operations from a DistributedExecutor in parallel

by Sanne Grinovero (JIRA)

Run local operations from a DistributedExecutor in parallel ----------------------------------------------------------- Key: ISPN-1294 URL: https://issues.jboss.org/browse/ISPN-1294 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.1.0.ALPHA1 Looking into {code}org.infinispan.distexec.DefaultExecutorService.invokeLocally(DistributedRunnableFuture<T>){code} It seems that the operations are performed in the same thread as the invoker; if we happen to send multiple operations to the local node, these are performed in sequence, and in sequence with the remote operations. We should use an Executor for the local tasks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
3
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

12 years, 3 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

12 years, 3 months

10
32
0 / 0

[JBoss JIRA] Created: (ISPN-1424) Implement non-blocking state transfer again on top of push-based state transfer

by Dan Berindei (JIRA)

Implement non-blocking state transfer again on top of push-based state transfer ------------------------------------------------------------------------------- Key: ISPN-1424 URL: https://issues.jboss.org/browse/ISPN-1424 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.0.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL Once we have the asymmetric caches support in we should be able to re-implement non-blocking state transfer. See the design document at http://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign#... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011