March 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2885) JMX operations do not expose parameter names

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2885?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2885: ---------------------------------- Fix Version/s: 5.2.3.Final > JMX operations do not expose parameter names > -------------------------------------------- > > Key: ISPN-2885 > URL: https://issues.jboss.org/browse/ISPN-2885 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.3.Final, 5.3.0.Final > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2852) CacheQuery.maxResults not honored everywhere

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2852?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-2852. ------------------------------------ Fix Version/s: 5.3.0.Alpha1 5.3.0.Final Resolution: Done > CacheQuery.maxResults not honored everywhere > -------------------------------------------- > > Key: ISPN-2852 > URL: https://issues.jboss.org/browse/ISPN-2852 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.2.Final > Reporter: Marko Lukša > Assignee: Marko Lukša > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > > CacheQuery.iterator() does not honor maxResults, while CacheQuery.list() does. Also, CacheQuery.getResultSize() apparently also ignores maxResults. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2879) Have ResultIterator implement AutoCloseable

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2879?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2879: --------------------------------------- it's not the CacheQuery which needs to be closed but the ResultIterator. So it's still nice to do but doesn't solve the implicit iteration problem. > Have ResultIterator implement AutoCloseable > -------------------------------------------- > > Key: ISPN-2879 > URL: https://issues.jboss.org/browse/ISPN-2879 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 6.0.0.Beta1 > > > Assuming we'll baseline on Java7, it would be very nice to have the following code valid and changing the default Fetch to LAZY: > {code} > Query query = queryBuilder.all().createQuery(); > CacheQuery cacheQuery = searchManager.getQuery(query, Bean.class); > for (Object object : cacheQuery) { > ... > }{code} > the problem is the implicit iterable opened needs to be closed. > see also ISPN-2874. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2879) Have ResultIterator implement AutoCloseable

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2879?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2879: ---------------------------------- Summary: Have ResultIterator implement AutoCloseable (was: Have CacheQuery implement AutoCloseable ) > Have ResultIterator implement AutoCloseable > -------------------------------------------- > > Key: ISPN-2879 > URL: https://issues.jboss.org/browse/ISPN-2879 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 6.0.0.Beta1 > > > Assuming we'll baseline on Java7, it would be very nice to have the following code valid and changing the default Fetch to LAZY: > {code} > Query query = queryBuilder.all().createQuery(); > CacheQuery cacheQuery = searchManager.getQuery(query, Bean.class); > for (Object object : cacheQuery) { > ... > }{code} > the problem is the implicit iterable opened needs to be closed. > see also ISPN-2874. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Thomas Fromm edited comment on ISPN-2886 at 3/4/13 1:58 PM: ------------------------------------------------------------ A solution could be introduce globalConfig.globalJmxStatistics().enabled() check in CacheManagerJmxRegistration.start() but this is in conflict with feature ISPN-2290 :-/ This makes it not easy to use DefaultCacheManager several times within an application without using one shared. How about making allowDuplicateDomain true as default, even when its nessesary always to register jmx? was (Author: tfromm): A solution could be introduce globalConfig.globalJmxStatistics().enabled() check in CacheManagerJmxRegistration.start() but this is in conflict with feature ISPN-2290 :-/ This makes it not easy to use DefaultCacheManager several times within an application without using one shared. > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Galder Zamarreño > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Thomas Fromm commented on ISPN-2886: ------------------------------------ A solution could be introduce globalConfig.globalJmxStatistics().enabled() check in CacheManagerJmxRegistration.start() but this is in conflict with feature ISPN-2290 :-/ This makes it not easy to use DefaultCacheManager several times within an application without using one shared. > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Thomas Fromm > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Thomas Fromm reassigned ISPN-2886: ---------------------------------- Assignee: Galder Zamarreño (was: Thomas Fromm) > Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException > ------------------------------------------------------------------------------ > > Key: ISPN-2886 > URL: https://issues.jboss.org/browse/ISPN-2886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Reporter: Thomas Fromm > Assignee: Galder Zamarreño > > Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. > org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2886) Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2886: ---------------------------------- Summary: Using multiple DefaultCacheManager w/o jmx leads to JmxDomainConflictException Key: ISPN-2886 URL: https://issues.jboss.org/browse/ISPN-2886 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 5.2.1.Final Reporter: Thomas Fromm Assignee: Thomas Fromm Creating multiple instances of DefaultCacheManager leads to CacheManagerJmxRegistrationTest, even when JMX is disabled in configuration. org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager" at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:171) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2767) Retrofit storeAsBinary to allow implementation of JSR107 store by value

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2767?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2767: ----------------------------------- Component/s: JCache > Retrofit storeAsBinary to allow implementation of JSR107 store by value > ------------------------------------------------------------------------ > > Key: ISPN-2767 > URL: https://issues.jboss.org/browse/ISPN-2767 > Project: Infinispan > Issue Type: Sub-task > Components: Core API, JCache, Marshalling > Affects Versions: 5.2.0.CR3 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance: > 1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation). > 2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour. > Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit. > I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need: > 1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ? > 2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that *always* stores a byte[] and never caches the object representation? -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2824) Excluive lock operation required to support invokeEntryProcessor()

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2824?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2824: ----------------------------------- Component/s: JCache > Excluive lock operation required to support invokeEntryProcessor() > ------------------------------------------------------------------ > > Key: ISPN-2824 > URL: https://issues.jboss.org/browse/ISPN-2824 > Project: Infinispan > Issue Type: Sub-task > Components: JCache, Locking and Concurrency > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > Exclusive lock semantics are needed within Infinispan in order to support JSR-107's invokeEntryProcessor() method. See dev thread for detailed information. -- 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2013