[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
[JBoss JIRA] Created: (ISPN-800) Infinispan inside OSGI
by luca stancapiano (JIRA)
Infinispan inside OSGI
----------------------
Key: ISPN-800
URL: https://jira.jboss.org/browse/ISPN-800
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 4.2.0.CR1
Reporter: luca stancapiano
Assignee: Manik Surtani
We need to import infinispan inside a OSGI repository. Tests are made with Felix.
I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan
I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI.
Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc)
Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles:
jboss transaction api 1.0.1.GA
(It is not yet a OSGI bundle. Waiting for a response to: https://jira.jboss.org/browse/JBEE-67)
jgroups 2.10.1.GA
(fixed in jgroups 1.12)
river 1.2.3.GA
marshalling-api 1.2.3.GA
jboss common core 2.2.14.GA
jboss logging spi 2.0.5.GA
rhq plugin annotations 1.4.0.B01
i18nlog 1.0.9
log4j 1.2.16
We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that:
1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan.
2 - it does not fail due to the dependency that is not really essential.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months