December 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-951) Infinispan Query module should load entities using getAsync

by Sanne Grinovero (JIRA)

Infinispan Query module should load entities using getAsync ----------------------------------------------------------- Key: ISPN-951 URL: https://issues.jboss.org/browse/ISPN-951 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.BETA1 Requires migration to new Loader API from Hibernate Search -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
9
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-956) Update RESTEasy version used by REST server

by Michal Linhard (JIRA)

Update RESTEasy version used by REST server ------------------------------------------- Key: ISPN-956 URL: https://issues.jboss.org/browse/ISPN-956 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Michal Linhard Assignee: Michal Linhard Priority: Minor Fix For: 4.2.1.FINAL, 5.0.0.BETA1 Update RESTEasy version (currently 2.0-beta-2) used by REST server to a stable one (2.0.1.GA or 2.1.0.GA). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
8
0 / 0

[JBoss JIRA] (ISPN-1557) Add use1PcForAutoCommitTransactions attribute to the new Configuration structure

by Mircea Markus (Created) (JIRA)

Add use1PcForAutoCommitTransactions attribute to the new Configuration structure -------------------------------------------------------------------------------- Key: ISPN-1557 URL: https://issues.jboss.org/browse/ISPN-1557 Project: Infinispan Issue Type: Bug Components: Configuration Reporter: Mircea Markus Assignee: Pete Muir Fix For: 5.1.0.CR1 use1PcForAutoCommitTransactions was added part of ISPN-1297, but I couldn't also update the new config due to ISPN-1552. The UT added in the description of ISPN-1552 actually tests the functionality required by this jira. Should be a straight-fwd thing to fix once ISPN-1552 is in place. -- 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

12 years, 12 months

7
8
0 / 0

[JBoss JIRA] (ISPN-1545) Enhance logging during cache shutdown

by Mircea Markus (Created) (JIRA)

Enhance logging during cache shutdown ------------------------------------- Key: ISPN-1545 URL: https://issues.jboss.org/browse/ISPN-1545 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.BETA5 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.CR1 When cache shuts down the transaction table recalculates its minViewId value based on the new topology. When the whole cluster shuts down though, the thread that recalculates might throw an exception (expected) because it's internal components (RPC in this example) are not responding anymore. This causes a lot of log noise in the logs, which should be removed: 2011-11-16 17:08:29,045 WARN [jta] (Transaction Reaper Worker 0) ARJUNA16045: attempted rollback of < formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffac11fa3e:c0a2:4ec3df75:a055, node_name=1, branch_uid=0:ffffac11fa3e:c0a2:4ec3df75:a056, eis_name=unknown eis name > (TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=< formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffac11fa3e:c0a2:4ec3df75:a055, node_name=1, branch_uid=0:ffffac11fa3e:c0a2:4ec3df75:a056, eis_name=unknown eis name >} LocalTransaction{remoteLockedNodes=[9124b480-6ae0-5267-d9f8-3d66ea7ec581, 86c0fc2d-a0da-adb4-5343-940d6bdb1aa0], isMarkedForRollback=true, transaction=TransactionImple < ac, BasicAction: 0:ffffac11fa3e:c0a2:4ec3df75:a055 status: ActionStatus.ABORTING >, lockedKeys=null, backupKeyLocks=null, viewId=1} org.infinispan.transaction.xa.LocalXaTransaction@2947}) failed with exception code - org.infinispan.CacheException: The cache has been stopped and invocations are not allowed! at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getViewId(JGroupsTransport.java:197) at org.infinispan.transaction.TransactionTable.getCurrentViewId(TransactionTable.java:372) at org.infinispan.transaction.TransactionTable.recalculateMinViewIdIfNeeded(TransactionTable.java:387) at org.infinispan.transaction.TransactionTable.removeLocalTransactionInternal(TransactionTable.java:318) at org.infinispan.transaction.TransactionTable.removeLocalTransaction(TransactionTable.java:306) at org.infinispan.transaction.xa.XaTransactionTable.removeLocalTransaction(XaTransactionTable.java:61) at org.infinispan.transaction.TransactionTable.failureCompletingTransaction(TransactionTable.java:188) at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:145) at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:136) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2869) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2848) at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1613) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) -- 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

12 years, 12 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1645) FileCacheStore.purgeInternal() not removes empty Bucket files

by Thomas Fromm (Created) (JIRA)

FileCacheStore.purgeInternal() not removes empty Bucket files ------------------------------------------------------------- Key: ISPN-1645 URL: https://issues.jboss.org/browse/ISPN-1645 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.CR2 Reporter: Thomas Fromm Assignee: Manik Surtani FileCacheStore leaves empty files inside storage directory after remove of cache entries. During a purgeInternal (by reaper thread) these files are found, but cannot be removed because loadBucket(..) always return null, because bucketFile.length() == 0. So updateBucket(..) will never reached and these files don't get removed. -- 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

12 years, 12 months

4
4
0 / 0

[JBoss JIRA] (ISPN-1546) FineGrainedAtomicMap key and value iterators are not threadsafe

by Sanne Grinovero (Created) (JIRA)

FineGrainedAtomicMap key and value iterators are not threadsafe --------------------------------------------------------------- Key: ISPN-1546 URL: https://issues.jboss.org/browse/ISPN-1546 Project: Infinispan Issue Type: Bug Components: Core API, Locking and Concurrency Reporter: Sanne Grinovero Assignee: Manik Surtani Invoking #keySet() or #values() might fail, even when using a transaction to isolate threads: {code} java.util.ConcurrentModificationException at org.infinispan.util.FastCopyHashMap$FasyCopyHashMapIterator.nextEntry(FastCopyHashMap.java:484) at org.infinispan.util.FastCopyHashMap$KeyIterator.next(FastCopyHashMap.java:560) at java.util.AbstractCollection.addAll(AbstractCollection.java:305) at org.infinispan.atomic.FineGrainedAtomicHashMapProxy.keySet(FineGrainedAtomicHashMapProxy.java:104) at org.hibernate.ogm.dialect.infinispan.InfinispanAssociationSnapshot.getRowKeys(InfinispanAssociationSnapshot.java:59) at org.hibernate.ogm.datastore.spi.Association.getKeys(Association.java:132) at org.hibernate.ogm.loader.OgmLoader.getResultSet(OgmLoader.java:420) at org.hibernate.ogm.loader.OgmLoader.doQuery(OgmLoader.java:248) at org.hibernate.ogm.loader.OgmLoader.doQueryAndInitializeNonLazyCollections(OgmLoader.java:215) at org.hibernate.ogm.loader.OgmLoader.loadCollection(OgmLoader.java:185) at org.hibernate.ogm.loader.OgmBasicCollectionLoader.initialize(OgmBasicCollectionLoader.java:42) at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:622) at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:82) at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1607) at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:379) at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:112) at org.hibernate.collection.internal.PersistentSet.iterator(PersistentSet.java:180) {code} -- 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

12 years, 12 months

10
30
0 / 0

[JBoss JIRA] (ISPN-1649) JDBC cache loader "dropTablesOnExit" does not work

by dex chen (Created) (JIRA)

JDBC cache loader "dropTablesOnExit" does not work -------------------------------------------------- Key: ISPN-1649 URL: https://issues.jboss.org/browse/ISPN-1649 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.CR1 Environment: ISPN 5.1.x, Java 7, H2 DB on Linux Reporter: dex chen Assignee: Manik Surtani I configure my JDBC cache loader with H2 engine using filesystem as store. I set the "dropTablesOnExit" to "true", but I still see the tables/and the data after I stop the cache. Basically, "dropTablesOnExist" has no effect. sample config: <loader class="org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore" fetchPersistentState="true" purgeOnStartup="false"> <properties> <property name="stringsTableNamePrefix" value="ISPN_STRING_TABLE"/> <property name="idColumnName" value="ID_COLUMN"/> <property name="dataColumnName" value="DATA_COLUMN"/> <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnType" value="BIGINT"/> <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/> <property name="connectionUrl" value="jdbc:h2:file:/tmp/testStore;DB_CLOSE_DELAY=-1"/> <property name="userName" value="sa"/> <property name="driverClass" value="org.h2.Driver"/> <property name="idColumnType" value="VARCHAR(255)"/> <property name="dataColumnType" value="BINARY"/> <property name="dropTableOnExit" value="true"/> <property name="createTableOnStart" value="true"/> </properties> </loader> -- 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

12 years, 12 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1604) use1PCForAutoCommitTransactions not completely added to new configuration

by Pete Muir (Created) (JIRA)

use1PCForAutoCommitTransactions not completely added to new configuration ------------------------------------------------------------------------- Key: ISPN-1604 URL: https://issues.jboss.org/browse/ISPN-1604 Project: Infinispan Issue Type: Bug Components: Configuration, Transactions Affects Versions: 5.1.0.CR1 Reporter: Pete Muir Assignee: Mircea Markus Fix For: 5.1.0.CR2 It's been added to the builder, but not the configuration class it builds, nor to the legacy adaptor or read methods. -- 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

12 years, 12 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1637) AsyncStore.enqueue() throws 'CacheException: Unable to enqueue asynchronous task' Instead of blocking when the queue is full

by Andrew Pushkin (Created) (JIRA)

AsyncStore.enqueue() throws 'CacheException: Unable to enqueue asynchronous task' Instead of blocking when the queue is full ---------------------------------------------------------------------------------------------------------------------------- Key: ISPN-1637 URL: https://issues.jboss.org/browse/ISPN-1637 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.CR1 Reporter: Andrew Pushkin Assignee: Manik Surtani Documentation http://docs.jboss.org/infinispan/5.1/apidocs/config.html#ce_loader_async : "modificationQueueSize int 1024 Sets the size of the modification queue for the async store. If updates are made at a rate that is faster than the underlying cache store can process this queue, then the async store behaves like a synchronous store for that period, blocking until the queue can accept more elements. (Javadoc)" However the async store doesn't "behaves like synchronous [...] blocking until the queue can accept more elements" because AsyncStore.enqueue() calls changesDeque.add(mod); But I guess it should call put() to wait queue to accept more elements. -- 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

12 years, 12 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2011