October 2010 - infinispan-issues - Jboss List Archives

[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-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-586) ManagedConnectionPool doesn't work in a transactional context

by Manik Surtani (JIRA)

ManagedConnectionPool doesn't work in a transactional context ------------------------------------------------------------- Key: ISPN-586 URL: https://jira.jboss.org/browse/ISPN-586 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 >From the reporter: "Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain. This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix." This possibly has to do with the AbstractCacheStore doing the following in prepare(): " public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } " and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores. -- 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, 6 months

8
25
0 / 0

[JBoss JIRA] Created: (ISPN-633) NotSerializableException seen on DIST deadlock detectioion

by Erik Salter (JIRA)

NotSerializableException seen on DIST deadlock detectioion ---------------------------------------------------------- Key: ISPN-633 URL: https://jira.jboss.org/browse/ISPN-633 Project: Infinispan Issue Type: Bug Affects Versions: 4.2.0.ALPHA1 Reporter: Erik Salter Assignee: Manik Surtani Attachments: infinispan-multiplethreads.tgz As reported on the forums: -- 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, 8 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-492) Use map implementations that do array equality based on contents

by Galder Zamarreno (JIRA)

Use map implementations that do array equality based on contents ---------------------------------------------------------------- Key: ISPN-492 URL: https://jira.jboss.org/browse/ISPN-492 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreno Assignee: Manik Surtani Make Infinispan use backing maps that do array equality based on its contents and not on reference. This would for example allow us to have maps with byte[] as keys without the need of wrapping these arrays into something else. This would need subclassing or reimplementing maps to make comparisons based on contents. An config option could be added if someone needed standard JDK map behavior. -- 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, 8 months

2
1
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, 10 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-556) house keeping of stale prepared transactions

by Mircea Markus (JIRA)

house keeping of stale prepared transactions -------------------------------------------- Key: ISPN-556 URL: https://jira.jboss.org/browse/ISPN-556 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final We will need a background cleanup thread to clean up stale prepares and ongoing txs that have exceeded a timeout (in cases where there is no backend TM and hence no recovery) - Timeout could be set by user (cfg) - Or by TM (XAResource.setTimeout()) Should also be able to release locks in this case -- 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

6
12
0 / 0

[JBoss JIRA] Created: (ISPN-701) Redesign TableManipulation in JDBC cache loader

by Trustin Lee (JIRA)

Redesign TableManipulation in JDBC cache loader ----------------------------------------------- Key: ISPN-701 URL: https://jira.jboss.org/browse/ISPN-701 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Trustin Lee Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final There are two on-going issues related with TableManipulation at the moment: ISPN-686 and ISPN-698. They both are related with vendor specific behavior, and the current implementation uses switch-cases to deal with the differences between vendors. Could we instead use inheritance to make the code look cleaner and easier to maintain? Hibernate does so: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/trunk/core/src/... Also, the properties like custom types, names, prefixes, fetch/batch sizes could be moved to AbstractJdbcCacheStoreConfig (or its subclass because we have mixed JDBC store) instead of exposing TableManipulation directly to a user. Since Hibernate already provides very well defined dialect metadata model, we could simply tap into it. However, we should wrap it with a simple wrapper class so that a user can configure the JDBC store without the knowledge of Hibernate. This is a backward incompatible change - will be done in 5.0, and TableManipulation and its related methods should be deprecated in 4.2. -- 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, 11 months

5
16
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2010