May 2010 - infinispan-issues - Jboss List Archives

[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-375) Enable Hot Rod clients to start transactions

by Galder Zamarreno (JIRA)

Enable Hot Rod clients to start transactions -------------------------------------------- Key: ISPN-375 URL: https://jira.jboss.org/jira/browse/ISPN-375 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 It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only. This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction. Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky. -- 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, 4 months

6
12
0 / 0

[JBoss JIRA] Created: (ISPN-303) Follow up Jopr demo ideas

by Galder Zamarreno (JIRA)

Follow up Jopr demo ideas ------------------------- Key: ISPN-303 URL: https://jira.jboss.org/jira/browse/ISPN-303 Project: Infinispan Issue Type: Task Components: JMX, reporting and management Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Ideas for a follow up Jopr demo: - Show ISPN-302 in action. - Heiko: About the monitoring schedules : in Administration->System Configuration->Templates you can also "predefine" this, so it gets applied to every new instance (and if wanted also to all existing instances). - Heiko: mention that 30 seconds is too too short for production -- 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, 5 months

3
5
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-203) REST interface to Infinispan DB

by Michael Neale (JIRA)

REST interface to Infinispan DB ------------------------------- Key: ISPN-203 URL: https://jira.jboss.org/jira/browse/ISPN-203 Project: Infinispan Issue Type: Feature Request Components: Cache Server, Querying Reporter: Michael Neale Assignee: Michael Neale Fix For: 5.1.0.BETA1 As described here: http://www.jboss.org/community/wiki/InfinispanDB This will build on (or perhaps be built in) the server/rest module - as well as some additions of helper classes to core, and a query language to query module. -- 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, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-449) Streaming over Hot Rod

by Galder Zamarreno (JIRA)

Streaming over Hot Rod ---------------------- Key: ISPN-449 URL: https://jira.jboss.org/browse/ISPN-449 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final Extend large object support/streaming to 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/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
6
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-284) Streamed rehashing

by Manik Surtani (JIRA)

Streamed rehashing ------------------ Key: ISPN-284 URL: https://jira.jboss.org/jira/browse/ISPN-284 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA Currently rehashing uses RPC which uses byte array representations of state. These could use streams, perhaps using JGroups' STREAMING_STATE_TRANSFER sockets, for greater performance and robustness. -- 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, 11 months

9
22
0 / 0

[JBoss JIRA] Created: (ISPN-263) Handle JGroups MERGE events to help deal with split brains

by Manik Surtani (JIRA)

Handle JGroups MERGE events to help deal with split brains ---------------------------------------------------------- Key: ISPN-263 URL: https://jira.jboss.org/jira/browse/ISPN-263 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.GA JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well. Analogous to JBCACHE-471 -- 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

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2010