September 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-1380) Modules using custom commands should use a defined range for commandIds

by Sanne Grinovero (JIRA)

Modules using custom commands should use a defined range for commandIds ----------------------------------------------------------------------- Key: ISPN-1380 URL: https://issues.jboss.org/browse/ISPN-1380 Project: Infinispan Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.ALPHA1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1365) Data left in inconsistent state on rehash.

by Erik Salter (JIRA)

Data left in inconsistent state on rehash. ------------------------------------------ Key: ISPN-1365 URL: https://issues.jboss.org/browse/ISPN-1365 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.FINAL Reporter: Erik Salter Assignee: Manik Surtani I'm seeing a lot of data inconsistencies on a rehash, especially if there is a lot of lock contention for keys on caches participating in a transaction. Attached is a unit test that can reproduce the problem quite readily. This uses the grouping API, eager locking of a single node, and the distribution framework to effect "local" transactions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
9
0 / 0

[JBoss JIRA] Created: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server

by Michal Linhard (JIRA)

support optimistic locking with ETags and If-Match in rest server ----------------------------------------------------------------- Key: ISPN-1084 URL: https://issues.jboss.org/browse/ISPN-1084 Project: Infinispan Issue Type: Feature Request Components: Cache Server Affects Versions: 5.0.0.CR1, 4.2.2.BETA1 Reporter: Michal Linhard Assignee: Trustin Lee currently it is not possible to do optimistic locking using the ETag feature in the REST server, because the "If-Match" HTTP header is ignored. We allow to put a value many times with the same "If-Match" header, but according to the spec: {quote} "A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge. " {quote} (copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

5
7
0 / 0

[JBoss JIRA] Created: (ISPN-1332) tree cache cannot be enabled for persistence due to serialization issue (java.io.NotSerializableException: org.infinispan.tree.NodeKey)

by Jan Slezak (JIRA)

tree cache cannot be enabled for persistence due to serialization issue (java.io.NotSerializableException: org.infinispan.tree.NodeKey) --------------------------------------------------------------------------------------------------------------------------------------- Key: ISPN-1332 URL: https://issues.jboss.org/browse/ISPN-1332 Project: Infinispan Issue Type: Bug Components: Tree API Affects Versions: 5.0.0.FINAL Reporter: Jan Slezak Assignee: Manik Surtani Priority: Critical If enabled persistence in treecache - using treecache leads to serialization issue: ERROR: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.eviction.PassivationManagerImpl.passivateAll() throws org.infinispan.loaders.CacheLoaderException on object at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:173) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:890) at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:716) at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:603) at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:205) at org.infinispan.CacheImpl.stop(CacheImpl.java:378) at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:599) at eu.ysoft.cache.replicator.IfspnReplicationBuffer.stop(IfspnReplicationBuffer.java:178) at eu.ysoft.cache.replicator.IfspnReplicationBufferTestsBase.destroy(IfspnReplicationBufferTestsBase.java:51) at eu.ysoft.cache.replicator.IfspnReplicationBufferTests.destroy(IfspnReplicationBufferTests.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202) at org.testng.internal.Invoker.invokeMethod(Invoker.java:753) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:842) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1166) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1178) at org.testng.TestRunner.privateRun(TestRunner.java:757) at org.testng.TestRunner.run(TestRunner.java:608) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1158) at org.testng.TestNG.runSuitesLocally(TestNG.java:1083) at org.testng.TestNG.run(TestNG.java:999) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111) at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:203) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170) ... 42 more Caused by: org.infinispan.loaders.CacheLoaderException: java.io.NotSerializableException: org.infinispan.tree.NodeKey at org.infinispan.loaders.jdbm.JdbmCacheStore.store0(JdbmCacheStore.java:317) at org.infinispan.loaders.jdbm.JdbmCacheStore.store(JdbmCacheStore.java:292) at org.infinispan.eviction.PassivationManagerImpl.passivateAll(PassivationManagerImpl.java:108) ... 47 more Caused by: java.io.NotSerializableException: org.infinispan.tree.NodeKey at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at jdbm.htree.HashBucket.writeExternal(HashBucket.java:270) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at jdbm.helper.Serialization.serialize(Serialization.java:75) at jdbm.helper.DefaultSerializer.serialize(DefaultSerializer.java:82) at jdbm.recman.BaseRecordManager.insert(BaseRecordManager.java:202) at jdbm.recman.CacheRecordManager.insert(CacheRecordManager.java:156) at jdbm.recman.CacheRecordManager.insert(CacheRecordManager.java:140) at jdbm.htree.HashDirectory.put(HashDirectory.java:233) at jdbm.htree.HTree.put(HTree.java:129) at org.infinispan.loaders.jdbm.JdbmCacheStore.store0(JdbmCacheStore.java:313) ... 49 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-1326) Multiplexes marshalling architecture

by Galder Zamarreño (JIRA)

Multiplexes marshalling architecture ------------------------------------ Key: ISPN-1326 URL: https://issues.jboss.org/browse/ISPN-1326 Project: Infinispan Issue Type: Enhancement Components: Marshalling Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1 The current solution for ISPN-1205 involves sending the cache name along with each MarshalledValue marshalled payload which is not optimal. The reason this is needed is to be able to locate the marshaller that the MV needs, which needs to be given on instance creation. To make this more efficient, a multiplexing marshalling architecture is needed where the cache name is marshalled way before anything else in the command and based on that, the right marshaller can be picked and passed down to the externalizers to use as needed, i.e. MarshalledValue. The reason for doing this separately to ISPN-1205 is because some decent restructuring is needed to get this done cos currently the cache name is embedded within the actual command parameters, which makes it ackward to select a marshaller there and then continue unmarshalling with that marshaller. -- 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-1360) Upgrade Query to use Hibernate Search 4

by Sanne Grinovero (JIRA)

Upgrade Query to use Hibernate Search 4 --------------------------------------- Key: ISPN-1360 URL: https://issues.jboss.org/browse/ISPN-1360 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.1.0.BETA1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-200) Distributed queries

by Manik Surtani (JIRA)

Distributed queries ------------------- Key: ISPN-200 URL: https://jira.jboss.org/jira/browse/ISPN-200 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Querying Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.GA The holy grail of querying. * Indexes are _never_ shared. * Each node maintains local indexes for state it is responsible for (-Dinfinispan.query.indexLocalOnly=true). * Indexes could be in memory or disk. * Queries themselves are distributed. * The query object is built and broadcast to the entire cluster. * Each node executes the query on its own _local_ index, returning results. * The calling node returns a CacheQuery impl that lazily fetches and collates results from the cluster. * I expect this Map/Reduce model to perform very well since the workload is split up and happens in parallel across multiple CPUs against much smaller (individual) datasets. * Works with all cache modes, including DIST. * Need to make sure duplicates are handled, as well as failover. -- 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

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1218) warning about IndexWorkFlushEventListener should not be logged

by Sanne Grinovero (JIRA)

warning about IndexWorkFlushEventListener should not be logged -------------------------------------------------------------- Key: ISPN-1218 URL: https://issues.jboss.org/browse/ISPN-1218 Project: Infinispan Issue Type: Bug Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Optional The following warning is logged by the Query engine, but it doesn't actually apply to Query: {quote}[org.hibernate.search.backend.impl.TransactionalWorker] It appears changes are being pushed to the index out of a transaction. Register the IndexWorkFlushEventListener listener on flush to correctly manage Collections!{quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-1373) Initialization of extensions (module properties) is unguarded

by Sanne Grinovero (JIRA)

Initialization of extensions (module properties) is unguarded ------------------------------------------------------------- Key: ISPN-1373 URL: https://issues.jboss.org/browse/ISPN-1373 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.FINAL Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.1.0.ALPHA1 The Query test suite is unstable as often some custom commands or the AbstractModuleLifecycle entry point are not registered, or are inconsistently. It turns out that org.infinispan.util.ModuleProperties stores state in static variables, and is not threadsafe: adding proper locking fixed all Query tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
2
0 / 0

[JBoss JIRA] Updated: (ISPN-61) Transaction 2-phase protocol optimizations

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-61: ------------------------------ Priority: Critical (was: Blocker) > Transaction 2-phase protocol optimizations > ------------------------------------------ > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2011