September 2009 - infinispan-issues

[JBoss JIRA] Created: (ISPN-143) Security needs to be considered

by Manik Surtani (JIRA)

Security needs to be considered ------------------------------- Key: ISPN-143 URL: https://jira.jboss.org/jira/browse/ISPN-143 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.GA We need to consider security for Infinispan. Storing state on the cloud only makes sense if the data can be secured. Both encryption and authentication need to be considered, and all levels (wire protocol, cache store, public API, server module, etc) need to be taken in to consideration. -- 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, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-201) make JDBC cache store use DB transactions for commit/rollback

by Mircea Markus (JIRA)

make JDBC cache store use DB transactions for commit/rollback ------------------------------------------------------------- Key: ISPN-201 URL: https://jira.jboss.org/jira/browse/ISPN-201 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.0.0.GA current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach). -- 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, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-159) Extended coalesced logic to other parts

by Galder Zamarreno (JIRA)

Extended coalesced logic to other parts --------------------------------------- Key: ISPN-159 URL: https://jira.jboss.org/jira/browse/ISPN-159 Project: Infinispan Issue Type: Feature Request Components: RPC, Transactions Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR1 Reuse same coalesced async cache store logic to: - Reduce size of replicable commands where N modifications are sent so that only latest state is sent. - Manage the async replication queue. -- 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, 2 months

3
9
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-132) FIFO queu support

by Bryan Grunow (JIRA)

FIFO queu support ----------------- Key: ISPN-132 URL: https://jira.jboss.org/jira/browse/ISPN-132 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Bryan Grunow Assignee: Manik Surtani Add support for retrieving entries from the cache via insertion (FIFO) order. For example, cache.getNext(); would return the next entry in the queue. -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-144) graph based deadlock detection

by Mircea Markus (JIRA)

graph based deadlock detection ------------------------------- Key: ISPN-144 URL: https://jira.jboss.org/jira/browse/ISPN-144 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.1.0.GA current deadlock detection impl only knows to look for deadlocks between two transactions: i.e. tx1 (k1,k2) tx (k2,k1). This might be enhanced with transitive deadlock detection check: tx1(k1,k2) tx2(k2,k3) tx3(k3,k1). In the previous example, if all transactions are done acquiring first lock we result in a deadlock. Needs further thinking. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-200) Distributed queries

by Manik Surtani (JIRA)

Distributed queries ------------------- Key: ISPN-200 URL: https://jira.jboss.org/jira/browse/ISPN-200 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Querying Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.GA The holy grail of querying. * Indexes are _never_ shared. * Each node maintains local indexes for state it is responsible for (-Dinfinispan.query.indexLocalOnly=true). * Indexes could be in memory or disk. * Queries themselves are distributed. * The query object is built and broadcast to the entire cluster. * Each node executes the query on its own _local_ index, returning results. * The calling node returns a CacheQuery impl that lazily fetches and collates results from the cluster. * I expect this Map/Reduce model to perform very well since the workload is split up and happens in parallel across multiple CPUs against much smaller (individual) datasets. * Works with all cache modes, including DIST. * Need to make sure duplicates are handled, as well as failover. -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-83) Remove dependency on JGroups FLUSH

by Manik Surtani (JIRA)

Remove dependency on JGroups FLUSH ---------------------------------- Key: ISPN-83 URL: https://jira.jboss.org/jira/browse/ISPN-83 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA FLUSH is needed to control messages not being sent when a new view is installed, as we have observed that without this, messages get dropped by the joiner. We need to find a better way to deal with this as FLUSH is expensive and not very scalable. -- 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, 5 months

4
28
0 / 0

[JBoss JIRA] Created: (ISPN-129) Ability to manage cluster-wide configuration via a central management console

by Manik Surtani (JIRA)

Ability to manage cluster-wide configuration via a central management console ----------------------------------------------------------------------------- Key: ISPN-129 URL: https://jira.jboss.org/jira/browse/ISPN-129 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.GA Perhaps a lightweight form of JBoss AS' profile service, or something similar. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-127) Ability to bring up/take down nodes based on SLAs

by Manik Surtani (JIRA)

Ability to bring up/take down nodes based on SLAs ------------------------------------------------- Key: ISPN-127 URL: https://jira.jboss.org/jira/browse/ISPN-127 Project: Infinispan Issue Type: Feature Request Components: JMX and reporting Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.GA Need to look at what JOPR can provide by way of bringing up or killing instances based on overall load. Perhaps other metrics such as time of day could be used as well. Would be very useful to help build out a truly 'elastic' data grid. -- 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

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2009