July 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1136) Locking optimization: for dist lock only main data owner

by Mircea Markus (JIRA)

Locking optimization: for dist lock only main data owner --------------------------------------------------------- Key: ISPN-1136 URL: https://issues.jboss.org/browse/ISPN-1136 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.1.FINAL Reporter: Mircea Markus Assignee: Manik Surtani Detailed here, as the 4th improvement: http://community.jboss.org/wiki/PossibleLockingImprovements As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1131) Locking optimization: acquire (write) locks at prepare time

by Mircea Markus (JIRA)

Locking optimization: acquire (write) locks at prepare time ----------------------------------------------------------- Key: ISPN-1131 URL: https://issues.jboss.org/browse/ISPN-1131 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final Detailed here, as the 1st improvement: http://community.jboss.org/wiki/PossibleLockingImprovements -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

4
18
0 / 0

[JBoss JIRA] Created: (ISPN-1190) ModuleProperties could cause memory leaks

by Galder Zamarreño (JIRA)

ModuleProperties could cause memory leaks ----------------------------------------- Key: ISPN-1190 URL: https://issues.jboss.org/browse/ISPN-1190 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.0.0.CR7 ModuleProperties can create class memory leaks, because it contains static collections with references to user defined class instances: {code}private static Map<Byte,Class<? extends ModuleCommandInitializer>> commandInitializers; private static Collection<Class<? extends ReplicableCommand>> moduleCommands;{code} Also, the following two collections could contain references to instances user defined classes in static collections: {code}private static Map<String,ModuleProperties> moduleProperties; private static Map<Byte,ModuleCommandFactory> commandFactories;{code} These collections should not be static, and their clearing should be guaranteed at stoppage time. Even if there's any issues at stoppage time, they should not leak and so any collections containing Class instances should be weakly referenced. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
13
0 / 0

[JBoss JIRA] Created: (ISPN-434) Creating a new distributed cache on a non-coordinator node causes rehashing to hang

by Manik Surtani (JIRA)

Creating a new distributed cache on a non-coordinator node causes rehashing to hang ----------------------------------------------------------------------------------- Key: ISPN-434 URL: https://jira.jboss.org/jira/browse/ISPN-434 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.1.0.ALPHA3 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.Final If a cluster is already formed (perhaps due to another cache instance being started, such as a replicated one) and subsequently a distributed cache is created and started, first on a non-coordinator node, the startup sequence will hang until the cache is also started on the coordinator. E.g., 1. C1 (coord) starts replicated cache 2. C2 starts replicated cache 3. C2 starts distributed cache 4. C1 starts distributed cache Step 3 will hang until step 4 completes. So unless these happen in different threads - on different servers - this rehash will hang. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1104) Upgrade to Scala 2.9.0.final

by Trustin Lee (JIRA)

Upgrade to Scala 2.9.0.final ---------------------------- Key: ISPN-1104 URL: https://issues.jboss.org/browse/ISPN-1104 Project: Infinispan Issue Type: Task Reporter: Trustin Lee Assignee: Trustin Lee Priority: Trivial Fix For: 5.0.0.FINAL, 5.0.0.CR3 Scala 2.9.0.final has been released with various bug fixes and improvements. It's backward compatible as long as the code is recompiled, so I assume it's safe to upgrade and we should upgrade because people will be using Scala 2.9 when 5.0.0.Final is out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
8
0 / 0

[JBoss JIRA] Created: (ISPN-1204) Allow to be DB schema independent

by Nicolas Filotto (JIRA)

Allow to be DB schema independent --------------------------------- Key: ISPN-1204 URL: https://issues.jboss.org/browse/ISPN-1204 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Nicolas Filotto Assignee: Manik Surtani The current code checks if a table exists thanks to con.getMetaData().getTables(...) which is totally DB schema dependent, your code allow us to specify the schema by prefixing the table name with the name of the schema in the config which is not really convenient in practice especially if we have a lot of config files. You could easily make your code fully DB schema independent by replacing the method org.infinispan.loaders.jdbc.TableManipulation.tableExists(Connection connection, String tableName) with this content: {code} public boolean tableExists(Connection connection, String tableName) { assertNotNull(getTableName(), "table name is mandatory"); Statement stmt = null; ResultSet trs = null; try { stmt = connection.createStatement(); trs = stmt.executeQuery("SELECT count(*) FROM " + tableName); return trs.next(); } catch (SQLException e) { if (log.isTraceEnabled()) { log.trace("SQLException occurs while checking the table " + tableName, e); } return false; } finally { JdbcUtil.safeClose(trs); JdbcUtil.safeClose(stmt); } } {code} I know that it is a much less elegant and standard approach but it allows to simplify so much the config that I think that it makes sense to at least think about at it more than one second. Be free to resolve it as won't fix if you don't find it relevant. FYI: We use the same approach in our product (EXOJCR-1374) with JBC and we successfully tested it on Oracle, MySQL, MS SQL, PostgreSQL, DB2 and Sybase -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
12
0 / 0

[JBoss JIRA] Created: (ISPN-448) Consider all topology cache updates to be done by coordinator in Hot Rod

by Galder Zamarreno (JIRA)

Consider all topology cache updates to be done by coordinator in Hot Rod ------------------------------------------------------------------------ Key: ISPN-448 URL: https://jira.jboss.org/browse/ISPN-448 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.BETA1 Based on the discussion below, consider all topology cache updates to be done by coordinator to avoid concurrency issues when updating it. > Looks good. > What is causing this unsuccessful add? If it is caused by timeouts due > to multiple caches operating on the same key an alternative would be > to only perform the operation on the coordinator and rest of the > members to have node added listeners ... Currently, each node when it starts, it's responsible of adding itself to the view and when it stops, it's responsible from removing itself. Apart from this, there's a crashed member listener running only in coordinator that detects whether any member left without updating the topology view. Your suggestion to have the coordinator control it all seems like could work and get around potential timeouts. I'll create a JIRA to investigate this but won't do it for CR1 since I'm expect this to be a major issue. Metadata size is small and it's not constantly uddated. -- 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

13 years, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-1191) Replace JGroups partial state transfer

by Vladimir Blagojevic (JIRA)

Replace JGroups partial state transfer -------------------------------------- Key: ISPN-1191 URL: https://issues.jboss.org/browse/ISPN-1191 Project: Infinispan Issue Type: Task Components: State transfer Affects Versions: 5.0.0.BETA2, 5.0.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Manik Surtani Fix For: 5.0.0.FINAL We should investigate dropping partial state transfer as per our discussions at http://lists.jboss.org/pipermail/infinispan-dev/2011-June/008538.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1194) Consolidate rehash and replication state retrieval code

by Manik Surtani (JIRA)

Consolidate rehash and replication state retrieval code ------------------------------------------------------- Key: ISPN-1194 URL: https://issues.jboss.org/browse/ISPN-1194 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 5.0.0.FINAL Reporter: Manik Surtani Assignee: Dan Berindei Priority: Blocker Fix For: 5.1.0.BETA1, 5.1.0.Final As discussed. Abstract the actual code that handles moving of state so that it can be used both for rehashing as well as state transfer for replicated caches, thereby removing dependence on JGroups' FLUSH and partial state transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1216) Separate delimiter processing lock timeouts in state transfer

by Galder Zamarreño (JIRA)

Separate delimiter processing lock timeouts in state transfer ------------------------------------------------------------- Key: ISPN-1216 URL: https://issues.jboss.org/browse/ISPN-1216 Project: Infinispan Issue Type: Enhancement Components: State transfer Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.FINAL It appears that majority of EOFException instances encountered during state transfer are due to lock acquisition problem in the processing lock. So, consider adding a different limiter when the processing lock timeout is encountered. This should allow the receiving end to know more about the exact problem encountered by the sender side and so could provide more hints to the user. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2011