May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2806) Add a more efficient FileCacheStore implementation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2806?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2806: ------------------------------------- [~dan.berindei] [~akostadinov] agreed with your points that this is work that is not worth duplicating. A reason to have a native cache store, as raised by community, is the number of dependencies an external store would bring. > Add a more efficient FileCacheStore implementation > -------------------------------------------------- > > Key: ISPN-2806 > URL: https://issues.jboss.org/browse/ISPN-2806 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Based on the feedback we got from community/users Infinispan needs a more efficient FileCacheStore implementation. See the [design document|https://community.jboss.org/wiki/FileCacheStoreRedesign] that contains several suggestion of implementing it. It would be nice to also have a benchmark written in order to evaluate the performance between various implementation suggestion. -- 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-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-761: ------------------------------- Labels: onboard potential_performance_hit (was: potential_performance_hit) > Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader > ------------------------------------------------------------------------- > > Key: ISPN-761 > URL: https://issues.jboss.org/browse/ISPN-761 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 4.2.0.BETA1 > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: onboard, potential_performance_hit > Fix For: 6.0.0.Final > > > Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated. > I think CacheLoaderInterceptor needs to implement the following methods: > Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable > Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable > Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable > Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable -- 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-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-761: ------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader > ------------------------------------------------------------------------- > > Key: ISPN-761 > URL: https://issues.jboss.org/browse/ISPN-761 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 4.2.0.BETA1 > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: potential_performance_hit > Fix For: 6.0.0.Final > > > Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated. > I think CacheLoaderInterceptor needs to implement the following methods: > Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable > Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable > Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable > Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable -- 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-2923) provides an optimal way to search and retrieve the first non null value

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2923?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2923: ------------------------------------- thanks for the clarification, indeed it makes sense to be able to stop a map reduce task before storming all the entries in the cache. > provides an optimal way to search and retrieve the first non null value > ----------------------------------------------------------------------- > > Key: ISPN-2923 > URL: https://issues.jboss.org/browse/ISPN-2923 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.5.Final > Reporter: Mathieu Lachance > Assignee: Vladimir Blagojevic > Priority: Minor > > It would be nice if infinispan could provide a way to the common problem of searching and retrieve the first non null value. > My attempt was to use the map reduce framework, but it would still scan all the keys and value even if the result as been found. Maybe Infinispan could provide a way to "stop" the map-reduce operation on all nodes when asked, ex, when the first non null value has been found ? -- 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-2923) provides an optimal way to search and retrieve the first non null value

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2923?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2923: -------------------------------- Priority: Minor (was: Major) > provides an optimal way to search and retrieve the first non null value > ----------------------------------------------------------------------- > > Key: ISPN-2923 > URL: https://issues.jboss.org/browse/ISPN-2923 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.5.Final > Reporter: Mathieu Lachance > Assignee: Vladimir Blagojevic > Priority: Minor > > It would be nice if infinispan could provide a way to the common problem of searching and retrieve the first non null value. > My attempt was to use the map reduce framework, but it would still scan all the keys and value even if the result as been found. Maybe Infinispan could provide a way to "stop" the map-reduce operation on all nodes when asked, ex, when the first non null value has been found ? -- 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-604) Re-design CacheStore transactions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-604?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-604: ------------------------------- Fix Version/s: 6.0.0.Beta1 (was: 5.3.0.Final) > Re-design CacheStore transactions > ---------------------------------- > > Key: ISPN-604 > URL: https://issues.jboss.org/browse/ISPN-604 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Transactions > Affects Versions: 4.0.0.Final, 4.1.0.CR2 > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Labels: as7-ignored, modshape > Fix For: 6.0.0.Beta1 > > > Current(4.1.x) transaction implementation in CacheStores is brocken in several ways: > 1st problem. > {code}AbstractCacheStore.prepare: > public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { > if (isOnePhase) { > applyModifications(mods); > } else { > transactions.put(tx, mods); > } > } > {code} > If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it). > 2nd problem. > This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue. > When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction. > Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection. > Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1] > This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource). > Suggested fix: > - the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now) > - this requires API changes in CacheStore, e.g. > void store(InternalCacheEntry entry) > should become > void store(InternalCacheEntry entry, GlobalTransaction gtx) > (gtx would be null if this is not a transactional call). > [1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction -- 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-2880) infinispan documentation discrepancy (keyset)

by Aleksandar Kostadinov (JIRA)

[ https://issues.jboss.org/browse/ISPN-2880?page=com.atlassian.jira.plugin.... ] Aleksandar Kostadinov commented on ISPN-2880: --------------------------------------------- Mircea, that is a better wording but the core issue was that API does NOT describe these methods as working only locally, while docs describe them as working only locally. If you know that they indeed work only locally disregarding cluster state, then this needs to also go to javadocs. Hope it is now clear what I meant. Regards. > infinispan documentation discrepancy (keyset) > --------------------------------------------- > > Key: ISPN-2880 > URL: https://issues.jboss.org/browse/ISPN-2880 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.2.Final > Reporter: Aleksandar Kostadinov > Assignee: Mircea Markus > > I'm seeing some discrepancy between documentation [1] and API docs [2]. In documentation the keySet() and other methods are listed as limited to local cache. In API docs they are only listed as prohibitively expensive but from the wording they seem NOT limited to local cache. > I think these both docs need to be put in sync by somebody that knows how it actually works. > [1] https://docs.jboss.org/author/display/ISPN/Using+the+Cache+API#UsingtheCa... > [2] http://docs.jboss.org/infinispan/5.2/apidocs/org/infinispan/api/BasicCach... -- 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-2515) org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer fails randomly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2515?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2515: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=855362, https://bugzilla.redhat.com/show_bug.cgi?id=960516 (was: https://bugzilla.redhat.com/show_bug.cgi?id=855362) > org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer fails randomly > --------------------------------------------------------------------------------------------------- > > Key: ISPN-2515 > URL: https://issues.jboss.org/browse/ISPN-2515 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.3.0.Beta2 > > Attachments: VersionedReplStateTransferTest_recent.log > > > The tests are failing during running testsuite for JDG. > You can find the logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear if the test is run separately. -- 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-2891) Gap in time between commit of transaction and actual value update

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2891: -------------------------------- Assignee: Mircea Markus (was: Galder Zamarreño) > Gap in time between commit of transaction and actual value update > ----------------------------------------------------------------- > > Key: ISPN-2891 > URL: https://issues.jboss.org/browse/ISPN-2891 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.1.Final > Reporter: Jim Crossley > Assignee: Mircea Markus > Labels: 5.2.x > Fix For: 5.3.0.Beta2, 5.3.0.Final > > Attachments: bad.log, good.log, pessimistic.log, ugly.log > > > Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on. > The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic. > We've confirmed the failure on 5.2.2 as well. > Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531... > So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test. > It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3. > These tests always pass locally. They only ever fail on CI, which runs *very* slowly. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2886?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2886: ------------------------------------- allowDuplicateDomains should solve this. > 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 > Priority: Minor > > 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013