September 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2183: ----------------------------------- Summary: Add the ability to fetch a set of keys at once (getAll) Key: ISPN-2183 URL: https://issues.jboss.org/browse/ISPN-2183 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
2
0 / 0

[JBoss JIRA] (ISPN-2033) JdbcBinaryCacheStore.purgeInternal() - releaseConnection() should be called in finally block.

by Jim Dunkerton (JIRA)

Jim Dunkerton created ISPN-2033: ----------------------------------- Summary: JdbcBinaryCacheStore.purgeInternal() - releaseConnection() should be called in finally block. Key: ISPN-2033 URL: https://issues.jboss.org/browse/ISPN-2033 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.2.FINAL Environment: JBoss 7.1.1 Final Reporter: Jim Dunkerton Assignee: Manik Surtani A potential memory leak of pooled DB connections is present in JdbcCacheBinaryStore. Observe the catch and finally blocks of the purgeInternal() method: catch (SQLException ex) { //if something happens make sure buckets locks are being release releaseLocks(expiredBuckets); connectionFactory.releaseConnection(conn); log.failedClearingJdbcCacheStore(ex); throw new CacheLoaderException("Failed clearing JdbcBinaryCacheStore", ex); } finally { JdbcUtil.safeClose(ps); JdbcUtil.safeClose(rs); } The pooled DB connection is not released unless an SQLException has been thrown. Contrast with JdbcStringBasedCacheStore.purgeInternal(): } catch (SQLException ex) { log.failedClearingJdbcCacheStore(ex); throw new CacheLoaderException("Failed clearing string based JDBC store", ex); } finally { JdbcUtil.safeClose(ps); connectionFactory.releaseConnection(conn); } When using a JdbcMixedCacheStore, I noticed a DB connection leak. It appeared that for every two connections being acquired, only one was being released. I believe it is down to the fact that the JdbcBinaryCacheStore inside the JdbcMixedCacheStore is not releasing its connections properly (i.e. in its finally block) whereas the JdbcStringBasedCacheStore is. I guess a workaround is to use only a JdbcStringBasedCacheStore, not a JdbcMixedCacheStore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
10
0 / 0

[JBoss JIRA] (ISPN-2291) Tx rollback during state transfer has stale locks

by Erik Salter (JIRA)

Erik Salter created ISPN-2291: --------------------------------- Summary: Tx rollback during state transfer has stale locks Key: ISPN-2291 URL: https://issues.jboss.org/browse/ISPN-2291 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.2.0.Alpha3 Reporter: Erik Salter Assignee: Mircea Markus There are stale locks that happened when a transaction failed due to a replication timeout to its peer node. The transaction contained grouped keys that were submitted to the primary owner. During execution of one such transaction, there was a state transfer, which changed ownership of these keys. Here's an example flow: The task executed and started a transaction. Since it was not the primary owner, it sent a LockControlCommand to the new owner. This call timed out, and a rollback was issued. The local transaction is completed, but subsequent attempts to lock this key fail. The logs can be found here: http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.83/server.log.gz http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.84/server.log.gz http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.85/server.log.gz -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
25
0 / 0

[JBoss JIRA] Created: (ISPN-503) collate keys in replication queue

by Mircea Markus (JIRA)

collate keys in replication queue ---------------------------------- Key: ISPN-503 URL: https://jira.jboss.org/browse/ISPN-503 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 4.1.0.BETA2 Reporter: Mircea Markus Assignee: Manik Surtani At the moment the replication queue is replicating all the keys. What it can do is to collate them, similar to the way cache stores are collating writes. E.g. 1. put(k,v1) 2. put(k,v2). This can be collated in put(k,v2), as put(k,v1) is redundant. This would optimize async replication in a way that cannot be handled by jgroups. -- 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

11 years, 6 months

4
8
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

11 years, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-330) Separate scheduled/unscheduled async cache store configuration

by Galder Zamarreno (JIRA)

Separate scheduled/unscheduled async cache store configuration -------------------------------------------------------------- Key: ISPN-330 URL: https://jira.jboss.org/jira/browse/ISPN-330 Project: Infinispan Issue Type: Sub-task Components: Configuration, Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement configuration that allows differentiation between scheduled/unscheduled strategies: <async enabled="true"> <scheduled frequency="1000" /> </async> <async enabled="true"> <unscheduled poolsize="50" /> </async> This format allows for easier extension of properties in scheduled/unscheduled modes. -- 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

11 years, 6 months

3
5
0 / 0

[JBoss JIRA] (ISPN-2320) X-Site MBeans for operations and statistics

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2320: ------------------------------------- Summary: X-Site MBeans for operations and statistics Key: ISPN-2320 URL: https://issues.jboss.org/browse/ISPN-2320 Project: Infinispan Issue Type: Feature Request Components: cross-site replication Affects Versions: 5.2.0.Alpha3 Reporter: Tristan Tarrant Assignee: Mircea Markus Fix For: 5.2.0.Final The new Backup* classes should add MBean operations for enabling/disabling x-site backup functionality temporarily, changing timeouts and attributes for retrieving statistics about success/failures/etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

2
4
0 / 0

[JBoss JIRA] (ISPN-2297) Cache restart doesn't work properly

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2297: ---------------------------------- Summary: Cache restart doesn't work properly Key: ISPN-2297 URL: https://issues.jboss.org/browse/ISPN-2297 Project: Infinispan Issue Type: Bug Reporter: Dan Berindei Assignee: Mircea Markus Cache restart has at least two issues: 1. If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it. 2. {{ComponentRegistry}} keeps a few components as fields to speed up access. These components are destroyed on {{stop()}} and re-created on {{start()}}, because they are volatile, but the field references are not updated. Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2330) JBossMarshaller uses wrong class resolver after stop/start

by Dennis Reed (JIRA)

Dennis Reed created ISPN-2330: --------------------------------- Summary: JBossMarshaller uses wrong class resolver after stop/start Key: ISPN-2330 URL: https://issues.jboss.org/browse/ISPN-2330 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.1.4.FINAL Reporter: Dennis Reed Assignee: Galder Zamarreño org.infinispan.marshall.jboss.JBossMarshaller initializes the classResolver in its inject() method and clears it in its stop() method. If the cache is stopped and restarted (for example when redeploying a clustered web app in EAP), the wrong class resolver is used. Either the classResolver should not be removed in stop() (testing with it removed did not show any class leaking issues), or it should be reset in start(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

6
24
0 / 0

[JBoss JIRA] (ISPN-2181) Allow to inject the current cache into Mapper/Reducer/Callable objects

by Nicolas Filotto (JIRA)

Nicolas Filotto created ISPN-2181: ------------------------------------- Summary: Allow to inject the current cache into Mapper/Reducer/Callable objects Key: ISPN-2181 URL: https://issues.jboss.org/browse/ISPN-2181 Project: Infinispan Issue Type: Enhancement Components: CDI integration Affects Versions: 5.2.0.ALPHA2 Reporter: Nicolas Filotto Assignee: Pete Muir Thanks to ISPN-1636, it is now possible to inject the cache into Mapper/Reducer/Callable objects however the cache injected is the default cache not the cache for which the MapReduceTask/DistributedExecutorService has been created which is quite error prone since we don't expect to get the default cache but the current cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

6
17
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2012