August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4574) PartitionHandling: consider less than numOwners partitions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4574?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4574: ------------------------------------ I've increased the priority, since this scenario would be pretty common with 2 servers and numOwners = 2. > PartitionHandling: consider less than numOwners partitions > ---------------------------------------------------------- > > Key: ISPN-4574 > URL: https://issues.jboss.org/browse/ISPN-4574 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > > If the following two conditions are simultaneously met during a split brain: > a) less than numOwners nodes leave > b) two clusters are formed having that size > Then both partitions would be considered as available. E.g. a cluster of 6 nodes with numOwners=4, with a split brain resulting in 3 and 3 nodes partitions. > We should add some logic to prevent this situation, e.g. by requiring the remaining partition to have at least numOwners members. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4581) Memory leak when H2 is used

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4581?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4581: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Memory leak when H2 is used > --------------------------- > > Key: ISPN-4581 > URL: https://issues.jboss.org/browse/ISPN-4581 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha5 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > When H2 is used in-memory (the default maven profile) it keeps the data until the JVM is shutdown. This may leak the test data from the between the JDBC tests and the JPA tests. > Change the tests to clear the data before closing the cache manager involved. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1599) Split entry locking in Data Lock(s) and Structure Lock(s)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1599?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-1599. -------------------------------- Fix Version/s: 5.3.0.Final Resolution: Done With the ISPN-3048 fix, the DataContainer's locks are used as internal locks (via {{DataContainer.compute()}}), and the LockContainer is only used for user-visible locks. > Split entry locking in Data Lock(s) and Structure Lock(s) > --------------------------------------------------------- > > Key: ISPN-1599 > URL: https://issues.jboss.org/browse/ISPN-1599 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > > See mailing list thread: > http://lists.jboss.org/pipermail/infinispan-dev/2011-December/009605.html > http://infinispan.markmail.org/thread/k7sucf5dnuenuuf7 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4569: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2765 I have changed the cluster registry to use the BatchModeTransactionManager TM. It will also suspend ongoing transactions during cluster registry cache operations, in case another cache also uses the same TM. > Inserting into cache with indexing fails for XA transactions > ------------------------------------------------------------ > > Key: ISPN-4569 > URL: https://issues.jboss.org/browse/ISPN-4569 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Transactions > Affects Versions: 7.0.0.Alpha5 > Reporter: Radim Vansa > Assignee: Dan Berindei > > If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using > {code} > cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false); > {code} > the test fails. The reason is in deadlock while updating {{ScopedKey}} in __cluster_registry_cache__ : It seems that on originator we create transaction with modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the regular prepare on the other node does not see it (it is not committed yet) and also tries to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock timeout, as the commit is waiting on the regular prepare to finish. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4597) Query interceptor should update index during commit

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4597: ---------------------------------- Summary: Query interceptor should update index during commit Key: ISPN-4597 URL: https://issues.jboss.org/browse/ISPN-4597 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Embedded Querying Affects Versions: 7.0.0.Alpha5 Reporter: Dan Berindei Assignee: Sanne Grinovero Fix For: 7.0.0.Beta1 {{QueryInterceptor}} updates indexes during {{visitPrepareCommand}}. However, a tx that was prepared successfully is not guaranteed to be actually committed (e.g. if another node fails to prepare, or if another XA resource fails). The index should only be updated during {{visitPrepareCommand}} if the prepare is 1-phase, otherwise it should be updated during {{visitCommitCommand}}. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4197) Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4197?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4197: --------------------------------------- I think we should also consider dropping the InvocationBatchingConfiguration* classes, since all the functionality can be implemented using the TransactionConfiguration* API > Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model > --------------------------------------------------------------------------------------------------- > > Key: ISPN-4197 > URL: https://issues.jboss.org/browse/ISPN-4197 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta1 > > > Suggested by Paul in https://issues.jboss.org/browse/WFLY-3227, makes sense. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3961) Search across multiple caches

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3961?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3961: --------------------------------------- [~anistor] is this a blocker for 7.0 or can we consider it a "nice to have"? > Search across multiple caches > ----------------------------- > > Key: ISPN-3961 > URL: https://issues.jboss.org/browse/ISPN-3961 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Sanne Grinovero > Fix For: 7.0.0.Final > > > This would conceptually mean moving the SearchManager from Cache scope to CacheManager scope, which would allow us to share HS search factory. Would also need to add indexing configuration at cache manager level. > Having a SearchManager at cache scope would still be desired for cases where the user needs to configure particular indexing settings for certain caches. > Regarding indexes, we could have one index per class or one index per class + cache name; remains to be decided. > See discussion here: http://markmail.org/message/oe4jeq4k73f44rts -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2826: ---------------------------------- Fix Version/s: 7.0.0.Beta1 > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Ray Tsang > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2826: ---------------------------------- Issue Type: Enhancement (was: Feature Request) > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Ray Tsang > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Sanne Grinovero reassigned ISPN-2826: ------------------------------------- Assignee: Sanne Grinovero (was: Adrian Nistor) > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Ray Tsang > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta1 > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2014