August 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1319) topology changes makes entire cluster inconsistent

by Jan Slezak (JIRA)

topology changes makes entire cluster inconsistent -------------------------------------------------- Key: ISPN-1319 URL: https://issues.jboss.org/browse/ISPN-1319 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.FINAL Environment: linux / devel environment / 1.6.0_26 Reporter: Jan Slezak Assignee: Manik Surtani Priority: Blocker Invoke timeout exception in replicated or distributed environment (the issue occurred in both) during topology change on producer node - after that the data may end up in inconsistent state on other nodes (in my case n+1 entities on some of the nodes). I tried that with many TM / ISPN configurations in sync mode using DummyTransactionManagerLookup. Same behavior using invocation batching ... example xml: <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:config:5.0 http://www.infinispan.org/schemas/infinispan-config-5.0.xsd" xmlns="urn:infinispan:config:5.0"> <global> <transport clusterName="ifprotocluster"/> </global> <default> <clustering mode="distribution"> <l1 enabled="false"/> <hash numOwners="100" rehashRpcTimeout="120000" /> <sync/> </clustering> <transaction transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup" syncRollbackPhase="true" syncCommitPhase="true" useEagerLocking="true" /> </default> </infinispan> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
5
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, 2 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, 3 months

5
16
0 / 0

[JBoss JIRA] Created: (ISPN-484) Querying over HotRod

by Galder Zamarreno (JIRA)

Querying over HotRod -------------------- Key: ISPN-484 URL: https://jira.jboss.org/browse/ISPN-484 Project: Infinispan Issue Type: Feature Request Components: Cache Server, Querying Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.1.0.Final Investigate how to allow Hot Rod servers to be queries, particularly since server stores key/values in serialized byte arrays. Also, look into how to improve the protocol to potentially allow remote querying. -- 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

4
7
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, 3 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-509) Enable listeners to be hooked to Hot Rod servers

by Galder Zamarreno (JIRA)

Enable listeners to be hooked to Hot Rod servers ------------------------------------------------ Key: ISPN-509 URL: https://jira.jboss.org/browse/ISPN-509 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.Final Enable Hot Rod servers to have listeners injected. At the moment, this would require some code to programatically start a Hot Rod server and associate the listener. This would not be nice cos such program would need to deal with command line parameters....etc. So, we need a way to put listeners into Hot Rod server. I can think of two options: - Enable listeners to be set via configuration XML. - Enable Hot Rod to be passed listeners via command line parameter and get Hot Rod to instantiating them. -- 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

6
13
0 / 0

[JBoss JIRA] Created: (ISPN-1239) Graceful shutdown should be supported

by Manik Surtani (JIRA)

Graceful shutdown should be supported ------------------------------------- Key: ISPN-1239 URL: https://issues.jboss.org/browse/ISPN-1239 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Dan Berindei Priority: Critical Fix For: 5.1.0.BETA1, 5.1.0.Final Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down. Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
18
0 / 0

[JBoss JIRA] Created: (ISPN-1325) Config reference for 5.0 is broken

by Galder Zamarreño (JIRA)

Config reference for 5.0 is broken ---------------------------------- Key: ISPN-1325 URL: https://issues.jboss.org/browse/ISPN-1325 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.ALPHA1 http://docs.jboss.org/infinispan/5.0/apidocs/config.html is broken. Fix it and generate a new version that can be uploaded. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1189) config schema - clustering mode should validate format of the string

by Michal Linhard (JIRA)

config schema - clustering mode should validate format of the string -------------------------------------------------------------------- Key: ISPN-1189 URL: https://issues.jboss.org/browse/ISPN-1189 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 5.0.0.CR5 Reporter: Michal Linhard Assignee: Manik Surtani Priority: Minor currently the schema for the clustering mode says it's a string and the mode is decided by first letter of the string. this means that any garbage starting with the correct letter may lead to use of a specific mode e.g.: lasjadgadfg -> local rhdbhgh -> replication dfghbmjfgh -> distribution IlkHhdf -> invalidation what about forcing only the documented values "For distribution, set mode to either 'd', 'dist' or 'distribution'. For replication, use either 'r', 'repl' or 'replication'. Finally, for invalidation, 'i', 'inv' or 'invalidation'." + LOCAL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2011