[JBoss JIRA] Created: (ISPN-557) support for same transaction touching multiple nodes (multiple VMs)
by Mircea Markus (JIRA)
support for same transaction touching multiple nodes (multiple VMs)
--------------------------------------------------------------------
Key: ISPN-557
URL: https://jira.jboss.org/browse/ISPN-557
Project: Infinispan
Issue Type: Feature Request
Components: Transactions
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 5.1.0.Final
E.g. if a distributed transaction managers touches two embedded Infinispan nodes within the same transaction.
Could be implemented using the Hot Rod client approach - but in an embedded fashion!
EmbeddedClient <-- implements logic above
Except comms are in-VM for local entries
And via RpcDispatcher for remote entries
RemoteClient extends EmbeddedClient
Adds proper HotRod layer for comms
Including failover, smart routing, etc.
--
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
12 years, 3 months
[JBoss JIRA] Created: (ISPN-871) Out-of-heap data container implementation
by Manik Surtani (JIRA)
Out-of-heap data container implementation
-----------------------------------------
Key: ISPN-871
URL: https://issues.jboss.org/browse/ISPN-871
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.1.0.BETA1, 5.1.0.Final
The DataContainer interface could be implemented using a off-heap impl in C, using mmap. It would require custom memory management (gc-lite?) to reclaim free space, as well as reimplementing of eviction algorithms to maintain the contract of a self-sizing data container, but the benefits of this would be the ability to address very large amounts of memory with minimal gc overhead from the JVM.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (ISPN-863) Eviction based on JVM memory utilization
by Dave Marion (JIRA)
Eviction based on JVM memory utilization
----------------------------------------
Key: ISPN-863
URL: https://issues.jboss.org/browse/ISPN-863
Project: Infinispan
Issue Type: Enhancement
Components: Eviction
Affects Versions: 4.2.0.Final
Environment: N/A
Reporter: Dave Marion
Assignee: Manik Surtani
Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[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
[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