December 2009 - infinispan-issues

[JBoss JIRA] Created: (ISPN-202) Fix QueryHelper to throw an exception if there are 2 instances of the QueryInterceptor running on a given cache's interceptor chain.

by Navin Surtani (JIRA)

Fix QueryHelper to throw an exception if there are 2 instances of the QueryInterceptor running on a given cache's interceptor chain. ------------------------------------------------------------------------------------------------------------------------------------ Key: ISPN-202 URL: https://jira.jboss.org/jira/browse/ISPN-202 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 4.0.0.CR1 Reporter: Navin Surtani Assignee: Manik Surtani -- 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

14 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-318) Locking could optionally be "fair"

by Manik Surtani (JIRA)

Locking could optionally be "fair" ---------------------------------- Key: ISPN-318 URL: https://jira.jboss.org/jira/browse/ISPN-318 Project: Infinispan Issue Type: Feature Request Components: Locking and Concurrency Affects Versions: 4.0.0.CR3 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.0.0.GA Would require a number of changes: 1. A new boolean field and getter/setter in Configuration.LockingType (follow patterns of other boolean flags here to ensure proper XSD and parser generation), perhaps called "useFairLocking", defaults to false. 2. Modify LockManagerImpl to pass this flag into the LockContainer implementations (in LockManagerImpl#startLockManager()) 3. Modify the 4 concrete LockContainer implementations to use this flag when creating new locks. Implementations that use JDK reentrant locks just need to pass the fairness flag into the ReentrantLock constructor. 4. Modify OwnableReentrantLock to handle fairness. Referring to the JDK's ReentrantLock.FairSync may help. OwnableReentrantLock combines features of the JDK ReentrantLock and ReentrantLock.NonFairSync into a single class, so perhaps the best approach is to create a new OwnableFairReentrantLock. -- 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

14 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-308) Remove dependency on RHQ PluginAnnotation SNAPSHOTs

by Manik Surtani (JIRA)

Remove dependency on RHQ PluginAnnotation SNAPSHOTs --------------------------------------------------- Key: ISPN-308 URL: https://jira.jboss.org/jira/browse/ISPN-308 Project: Infinispan Issue Type: Task Components: JMX, reporting and management Reporter: Manik Surtani Assignee: Galder Zamarreno Priority: Blocker Fix For: 4.0.0.CR3 The dependency on org.rhq.helpers:rhq-pluginAnnotations to be moved from 1.4.0-SNAPSHOT to something that isn't a moving target. I believe the RHQ team will have published this by 9th Dec 2009. -- 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

14 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-305) Make dependency on c3p0 optional for cachestore-jdbc

by Sanne Grinovero (JIRA)

Make dependency on c3p0 optional for cachestore-jdbc ---------------------------------------------------- Key: ISPN-305 URL: https://jira.jboss.org/jira/browse/ISPN-305 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.0.0.CR2 Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 4.0.0.CR3 PooledConnectionFactory makes use of c3p0, while it's possible to use other connectionFactories which don't need the dependency. (I don't need it when deploying on AS) Setting <optional>true</optional> in pom.xml should be enough? -- 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

14 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-306) Delete deprecated class DataManiulationHelper in cachestore-jdbc

by Sanne Grinovero (JIRA)

Delete deprecated class DataManiulationHelper in cachestore-jdbc ---------------------------------------------------------------- Key: ISPN-306 URL: https://jira.jboss.org/jira/browse/ISPN-306 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 4.0.0.CR3 I've deprecated org.infinispan.loaders.jdbc.DataManiulationHelper because of a typo in the classname, so currently the code is duplicated. Please delete the old named class when you feel it's safe. -- 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

14 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-225) Investigate whether HHH-3817 and HHH-3818 affter the Infinispan cache provider

by Galder Zamarreno (JIRA)

Investigate whether HHH-3817 and HHH-3818 affter the Infinispan cache provider ------------------------------------------------------------------------------ Key: ISPN-225 URL: https://jira.jboss.org/jira/browse/ISPN-225 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.GA Check whether these two jiras affect the Infinispan cache provider: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817 http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818 -- 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

14 years, 5 months

1
7
0 / 0

[JBoss JIRA] Created: (ISPN-287) Querying to support arbitrary key types (not just String)

by Manik Surtani (JIRA)

Querying to support arbitrary key types (not just String) --------------------------------------------------------- Key: ISPN-287 URL: https://jira.jboss.org/jira/browse/ISPN-287 Project: Infinispan Issue Type: Feature Request Components: Querying Affects Versions: 4.0.0.CR2 Reporter: Manik Surtani Assignee: Navin Surtani Fix For: 4.0.0.GA Based on the discussions we had, we should be able to annotate arbitrary key types and provide a transformer so that we can use arbitrary keys with Lucene. -- 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

14 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-277) LRU data container endlesly looping or containing heavily

by Galder Zamarreno (JIRA)

LRU data container endlesly looping or containing heavily --------------------------------------------------------- Key: ISPN-277 URL: https://jira.jboss.org/jira/browse/ISPN-277 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 4.0.0.CR2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Priority: Critical Attachments: td2.txt Something around LRU container is not working fine. The attached log from an concurrency test in the 2nd level cache shows that in 3 thread dumps taken over 30 seconds appart, UserRunnerThread-5 is stuck in: "UserRunnerThread-5" prio=10 tid=0x6f65bc00 nid=0xdea runnable [0x05efb000] java.lang.Thread.State: RUNNABLE at org.infinispan.container.FIFODataContainer$LinkedEntry.casNext(FIFODataContainer.java:180) at org.infinispan.container.FIFODataContainer.correctPrev(FIFODataContainer.java:329) at org.infinispan.container.FIFODataContainer.linkAtEnd(FIFODataContainer.java:252) at org.infinispan.container.LRUDataContainer.put(LRUDataContainer.java:70) at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:161) at org.infinispan.interceptors.LockingInterceptor.commitEntry(LockingInterceptor.java:298) at org.infinispan.interceptors.LockingInterceptor.cleanupLocks(LockingInterceptor.java:281) at org.infinispan.interceptors.LockingInterceptor.doAfterCall(LockingInterceptor.java:243) at org.infinispan.interceptors.LockingInterceptor.visitPutKeyValueCommand(LockingInterceptor.java:200) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.MarshalledValueInterceptor.visitPutKeyValueCommand(MarshalledValueInterceptor.java:93) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:185) at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:48) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:34) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:269) at org.infinispan.CacheDelegate.putIfAbsent(CacheDelegate.java:422) at org.infinispan.CacheDelegate.putIfAbsent(CacheDelegate.java:153) at org.infinispan.CacheDelegate.putForExternalRead(CacheDelegate.java:243) at org.hibernate.cache.infinispan.util.CacheAdapterImpl.putForExternalRead(CacheAdapterImpl.java:115) at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.putFromLoad(TransactionalAccessDelegate.java:91) at org.hibernate.cache.infinispan.collection.TransactionalAccess.putFromLoad(TransactionalAccess.java:44) at org.hibernate.engine.loading.CollectionLoadContext.addCollectionToCache(CollectionLoadContext.java:333) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:279) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:245) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:218) at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:901) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:886) at org.hibernate.loader.Loader.doQuery(Loader.java:750) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:257) at org.hibernate.loader.Loader.loadCollection(Loader.java:2019) at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:62) at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:628) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:83) at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1817) at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:366) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:108) at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:131) at org.hibernate.collection.PersistentSet.isEmpty(PersistentSet.java:169) at org.hibernate.test.cache.infinispan.functional.ConcurrentWriteTest.getFirstContact(ConcurrentWriteTest.java:405) at org.hibernate.test.cache.infinispan.functional.ConcurrentWriteTest.access$0(ConcurrentWriteTest.java:397) at org.hibernate.test.cache.infinispan.functional.ConcurrentWriteTest$UserRunner.contactExists(ConcurrentWriteTest.java:519) at org.hibernate.test.cache.infinispan.functional.ConcurrentWriteTest$UserRunner.call(ConcurrentWriteTest.java:540) at org.hibernate.test.cache.infinispan.functional.ConcurrentWriteTest$UserRunner.call(ConcurrentWriteTest.java:1) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) This concurrency test does not get to finish in over a minute. However, once LRU is switched to NONE or FIFO, the test runs in 5 seconds. So, something looks fishy with LRU. -- 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

14 years, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (ISPN-301) Closing the Lucene Directory will close the cache too

by Sanne Grinovero (JIRA)

Closing the Lucene Directory will close the cache too ----------------------------------------------------- Key: ISPN-301 URL: https://jira.jboss.org/jira/browse/ISPN-301 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.0.0.CR2 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.CR3 Closing the cache is wrong as design as the cache is externally provided, so the Directory is not in charge of lifecycle managing. -- 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

14 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-294) Stop exposing getCache(*) via JMX and instead create new startCache(*) JMX methods

by Galder Zamarreno (JIRA)

Stop exposing getCache(*) via JMX and instead create new startCache(*) JMX methods ---------------------------------------------------------------------------------- Key: ISPN-294 URL: https://jira.jboss.org/jira/browse/ISPN-294 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 4.0.0.CR2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.GA In summary: Stop exposing getCache(*) methods via JMX and instead create managed startCache(*) methods to control Cache lifecycles via JMX. > On 30 Nov 2009, at 15:37, Brian Stansberry wrote: > >> On 11/26/2009 07:57 AM, Galder Zamarreno wrote: >>> >>> >>> On 11/26/2009 12:34 PM, Manik Surtani wrote: >>>> >>>> On 25 Nov 2009, at 21:08, Brian Stansberry wrote: >>>> >>>>> FYI; $subject is an interesting aspect of how we manage JBC >>>>> instances. This impacts things like ClusteredSingleSignOn and >>>>> clustered web session failover[1]. >>>>> >>>>> AIUI, this is less of an issue with Infinispan, since Cache instances >>>>> aren't shared (unless of course the code that asked for a Cache >>>>> passes around refs). Dunno if there is any equivalent to the >>>>> CacheJmxWrapperMBean.getCache() method though. >>>> >>>> Infinispan's CacheManager does this... >>> >>> Indeed. getCache() methods are exposed by JMX in order to start Cache >>> instances. If returning a Cache ref is a problem from a JMX perspective, >>> we can add remove @ManagedOperation from getCache() calls and add 2 >>> managed equivalent methods called something like startCache() that are >>> exposed via JMX. >>> >> >> That sounds like a good change just from an API point-of-view, at least if you don't really want to expose the cache via JMX. > > Yes, I agree with this. Galder, is there any reason other than controlling lifecycle that you expose a Cache via JMX? If there isn't any other reason then lets expose lifecycle helpers via the CacheManager. Much more robust IMO. To clarify, we only expose the Cache via JMX as a side effect of want to control lifecycle. I didn't do this on purpouse. We discussed it in the dev list and found using the getCache(*) method as a good way to solve the problem at the time which was controlling lifecycle, not to expose the Caches in any way. So, I'm all in to expose startCache(*) like methods for JMX and that way we don't leak Cache. I'll get this done asap. -- 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

14 years, 5 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2009