December 2011 - infinispan-issues

[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

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

12 years, 3 months

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

[JBoss JIRA] Created: (ISPN-686) JdbcStringBasedCacheStore loads previous data from store before an insert

by Sanne Grinovero (JIRA)

JdbcStringBasedCacheStore loads previous data from store before an insert ------------------------------------------------------------------------- Key: ISPN-686 URL: https://jira.jboss.org/browse/ISPN-686 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final, 4.0.0.Final Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.2.0.Final, 5.0.0.Final The JdbcStringBasedCacheStore implementation loads the previous data on an insert to find out if it should generate an UPDATE or INSERT statement, while it would perform much better to just verify if the primary key exists. On top of this, some databases provide ways to avoid the need to check at all, like MySQL's " INSERT ... ON DUPLICATE KEY UPDATE" [http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html] -- 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

7
29
0 / 0

[JBoss JIRA] Created: (ISPN-1346) Transactional listeners method order problem

by Tomas Fecko (JIRA)

Transactional listeners method order problem -------------------------------------------- Key: ISPN-1346 URL: https://issues.jboss.org/browse/ISPN-1346 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 5.0.0.FINAL Environment: fedora, windows Reporter: Tomas Fecko Assignee: Manik Surtani I'm using listeners as from the @Listener javadoc examples. When I register listener on VM where the cache is and put items to it, the methods of my listener are called in this order: @TransactionRegistered startTransaction @CacheEntryCreated handleEvent @CacheEntryCreated handleEvent @TransactionCompleted endTransaction which is as it should be, but when I register listener on second node, and put to cache in first node, methods on listener on second node are called in order: handleEvent handleEvent startTransaction endTransaction -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

9
18
0 / 0

[JBoss JIRA] Created: (ISPN-750) Infinispan servers should be accessible via SSL sockets

by Galder Zamarreño (JIRA)

Infinispan servers should be accessible via SSL sockets ------------------------------------------------------- Key: ISPN-750 URL: https://jira.jboss.org/browse/ISPN-750 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1, 5.1.0.Final Clients should be able to configure Hot Rod/Memcached servers for SSL access, in order to encrypt communications. -- 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, 4 months

2
3
0 / 0

[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

6
61
0 / 0

[JBoss JIRA] Created: (ISPN-1195) Rehashing and state transfer to use digesting

by Manik Surtani (JIRA)

Rehashing and state transfer to use digesting --------------------------------------------- Key: ISPN-1195 URL: https://issues.jboss.org/browse/ISPN-1195 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Dan Berindei Priority: Critical Fix For: 5.1.0.BETA1, 5.1.0.Final Rather than pushing entire state to new joiners, a mechanism of digests should be used to minimise network transfers. For example, Merkle trees can be used to determine which entries are out of date and need pushing, in the case of nodes that persist to a local cache store, and is restarted but still has access to some state on disk. This would require versioned entries though. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2011