March 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1636) Have remoted tasks inject services via CDI before execution

by Sanne Grinovero (Created) (JIRA)

Have remoted tasks inject services via CDI before execution ----------------------------------------------------------- Key: ISPN-1636 URL: https://issues.jboss.org/browse/ISPN-1636 Project: Infinispan Issue Type: Feature Request Components: CDI integration, Core API Reporter: Sanne Grinovero Assignee: Pete Muir Fix For: 6.0.0.FINAL Second step if what was discussed on: http://infinispan.markmail.org/search/#query:+page:1+mid:3dqf7hvuabttkqli... http://community.jboss.org/message/642300#642300 ISPN-1634 should provide Cache references only, this one should provide anything the CDI container knows about as defined by injection points in the remoted tasks; injection should happen again on each node, avoiding serialization of the injected components. -- 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

13 years, 6 months

7
15
0 / 0

[JBoss JIRA] (ISPN-1634) Provide references to Cache to distributed executor tasks and MapReduce tasks

by Sanne Grinovero (Created) (JIRA)

Provide references to Cache to distributed executor tasks and MapReduce tasks ----------------------------------------------------------------------------- Key: ISPN-1634 URL: https://issues.jboss.org/browse/ISPN-1634 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.1.0.FINAL As discussed on: http://infinispan.markmail.org/search/#query:+page:1+mid:3dqf7hvuabttkqli... http://community.jboss.org/message/642300#642300 Tasks being deserialized on remote nodes might need a reference to the Cache they are executed on; should be very useful both for distributed executer and for Map/Reduce use cases. -- 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

13 years, 6 months

3
6
0 / 0

[JBoss JIRA] (ISPN-1665) Add combiner function to MapReduce

by Ondrej Nevelik (Created) (JIRA)

Add combiner function to MapReduce ---------------------------------- Key: ISPN-1665 URL: https://issues.jboss.org/browse/ISPN-1665 Project: Infinispan Issue Type: Feature Request Reporter: Ondrej Nevelik Assignee: Vladimir Blagojevic Add functionality to optionally use a combiner between Map and Reduce phases (see http://research.google.com/archive/mapreduce.html part 4.3 Combiner Function). This enables to adjust API to be less restrictive - Reduce.reduce function could consume and return different types of objects. -- 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

13 years, 6 months

4
3
0 / 0

[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

13 years, 6 months

2
5
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

13 years, 6 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

13 years, 6 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

13 years, 6 months

4
6
0 / 0

[JBoss JIRA] (ISPN-1957) Improve internal data structures in the L1Manager

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1957: ----------------------------------- Summary: Improve internal data structures in the L1Manager Key: ISPN-1957 URL: https://issues.jboss.org/browse/ISPN-1957 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 5.1.3.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL The L1Manager contains a multimap of keys to servers and their timestamps, to know where to send invalidation messages. This is currently implemented as a CHM of CHMs, and can be very bulky and inefficient. -- 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

13 years, 6 months

3
4
0 / 0

[JBoss JIRA] (ISPN-1823) Revisit internal collections used and replace with custom, high performance constructs

by Manik Surtani (JIRA)

Manik Surtani created ISPN-1823: ----------------------------------- Summary: Revisit internal collections used and replace with custom, high performance constructs Key: ISPN-1823 URL: https://issues.jboss.org/browse/ISPN-1823 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 5.1.0.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Priority: Critical Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Most JDK collections are too inefficient for internal use, such as within contexts, cache transactions, etc. -- 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

13 years, 6 months

3
4
0 / 0

[JBoss JIRA] (ISPN-1862) fire TransactionCompletedEvent not as part of the transaction

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-1862: ---------------------------------- Summary: fire TransactionCompletedEvent not as part of the transaction Key: ISPN-1862 URL: https://issues.jboss.org/browse/ISPN-1862 Project: Infinispan Issue Type: Enhancement Components: Core API Affects Versions: 5.1.1.FINAL Reporter: Thomas Fromm Assignee: Manik Surtani When catching TransactionCompletedEvent I would expect, the transaction is committed, especially when isTransactionSuccessful() == true. I need to perform some operations after a transaction was completed. My workaround is ATM to suspend the transaction, perform my (async) stuff, and resume it afterwards. But in case of errors after resume, I get another TransactionCompletedEvent for this transaction with isTransactionSuccessful() == false. You see, I need something like a TransactionReallyCompletedEvent :-) My change request is, that the TransactionCompletedEvents should be fired, after the transaction was committed. -- 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

13 years, 7 months

4
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2012