November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3755) Add more detailed description of the filtering operators supported by the new query DSL

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3755?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3755: -------------------------------- Labels: 620 (was: ) > Add more detailed description of the filtering operators supported by the new query DSL > --------------------------------------------------------------------------------------- > > Key: ISPN-3755 > URL: https://issues.jboss.org/browse/ISPN-3755 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 620 > > The documentation exists (http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_filtering_op...), but is a bit scarce. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ] Work on ISPN-3335 started by Adrian Nistor. > JMX statistics for Queries partially doesn't work > ------------------------------------------------- > > Key: ISPN-3335 > URL: https://issues.jboss.org/browse/ISPN-3335 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha1 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > Attachments: QueryMBeanTest.java > > > I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query. > The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected: > getNumberOfIndexedEntities(String entity) > clear() > I've tried also to retrieve the statistics using the following method: > {code} > Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime() > {code} > and it returns the same results as if getting via JMX. > You can find the whole running test attached. > Best regards, > Anna. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3335: ------------------------------------- This seems to be caused by a bug in the way MutableSearchFactory of Hibernate Search is reconfigured when new indexable classes are found in cache. A new copy of the factory is created and all configs are copied from the previous. The statistics object is not (including the enable statistics flag) - this was overlooked maybe. This can be immediately worked around in Infinispan by reimplementing the query statistics mbean to not rely on it being copied during search factory reconfiguration, as the original one does. But this is a messy workaround, so I'll file an issue on Hibernate Search and see when can they provide a proper fix. > JMX statistics for Queries partially doesn't work > ------------------------------------------------- > > Key: ISPN-3335 > URL: https://issues.jboss.org/browse/ISPN-3335 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha1 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > Attachments: QueryMBeanTest.java > > > I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query. > The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected: > getNumberOfIndexedEntities(String entity) > clear() > I've tried also to retrieve the statistics using the following method: > {code} > Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime() > {code} > and it returns the same results as if getting via JMX. > You can find the whole running test attached. > Best regards, > Anna. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3756) Unnecessary wall clock call for immortal entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3756?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3756: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2237 > Unnecessary wall clock call for immortal entries > ------------------------------------------------ > > Key: ISPN-3756 > URL: https://issues.jboss.org/browse/ISPN-3756 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.1.0.Final > > > When updating immortal entries Infinispan calls up the wall clock time unnecessarily. > {code} > if (e != null) { > e.setValue(v); > InternalCacheEntry original = e; > e = entryFactory.update(e, metadata); > // we have the same instance. So we need to reincarnate. > if (original == e) { > --> e.reincarnate(timeService.wallClockTime()); > } > } else { > // this is a brand-new entry > e = entryFactory.create(k, v, metadata); > } > {code} -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3721) Extend remote get test scenarios to test the joiner state

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3721?page=com.atlassian.jira.plugin.... ] Work on ISPN-3721 started by Pedro Ruivo. > Extend remote get test scenarios to test the joiner state > --------------------------------------------------------- > > Key: ISPN-3721 > URL: https://issues.jboss.org/browse/ISPN-3721 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.1.0.Final > > > I got a failure in testScenario6, and I think it's because the originator retried the get command on the joiner, but the joiner hadn't installed the currentTopology+2 topology, and ClusteredGetCommand.perform() returned an unsure response. I guess I we'll have to rethink the unsure response stuff after all... > Here's the log: https://www.dropbox.com/s/dka0vdwm719klkm/RemoteGetDusingStateTransfer.tgz -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3048: ----------------------------------- [~dan.berindei] the size-based eviction is performed under the segment lock in BCHM. How can you loose data? With passivation enabled, I understand that, currently, data can be lost. > Eviction needs to be transactional > ---------------------------------- > > Key: ISPN-3048 > URL: https://issues.jboss.org/browse/ISPN-3048 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.3.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > > Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored. > We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3740) AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3740?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3740: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2236 > AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer > ------------------------------------------------------------------------------------ > > Key: ISPN-3740 > URL: https://issues.jboss.org/browse/ISPN-3740 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1 > > > The number of tests that use {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} and actually require state transfer to be disabled is insignificant: after commenting out the line that disables ST, I got 0 failures. > The Infinispan default is to have state transfer enabled, so developers naturally assume that state transfer is enabled all the time. It would be much clearer if {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} used the same defaults. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3740) AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3740?page=com.atlassian.jira.plugin.... ] Work on ISPN-3740 started by Pedro Ruivo. > AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer > ------------------------------------------------------------------------------------ > > Key: ISPN-3740 > URL: https://issues.jboss.org/browse/ISPN-3740 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1 > > > The number of tests that use {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} and actually require state transfer to be disabled is insignificant: after commenting out the line that disables ST, I got 0 failures. > The Infinispan default is to have state transfer enabled, so developers naturally assume that state transfer is enabled all the time. It would be much clearer if {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} used the same defaults. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3756) Unnecessary wall clock call for immortal entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3756?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-3756: -------------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > Unnecessary wall clock call for immortal entries > ------------------------------------------------ > > Key: ISPN-3756 > URL: https://issues.jboss.org/browse/ISPN-3756 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.1.0.Final > > > When updating immortal entries Infinispan calls up the wall clock time unnecessarily. > {code} > if (e != null) { > e.setValue(v); > InternalCacheEntry original = e; > e = entryFactory.update(e, metadata); > // we have the same instance. So we need to reincarnate. > if (original == e) { > --> e.reincarnate(timeService.wallClockTime()); > } > } else { > // this is a brand-new entry > e = entryFactory.create(k, v, metadata); > } > {code} -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3756) Unnecessary wall clock call for immortal entries

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-3756: -------------------------------------- Summary: Unnecessary wall clock call for immortal entries Key: ISPN-3756 URL: https://issues.jboss.org/browse/ISPN-3756 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.Final Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 6.1.0.Final When updating immortal entries Infinispan calls up the wall clock time unnecessarily. {code} if (e != null) { e.setValue(v); InternalCacheEntry original = e; e = entryFactory.update(e, metadata); // we have the same instance. So we need to reincarnate. if (original == e) { --> e.reincarnate(timeService.wallClockTime()); } } else { // this is a brand-new entry e = entryFactory.create(k, v, metadata); } {code} -- 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, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013