May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5217) Add factory to all existing Cache store impementations

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5217?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5217: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Add factory to all existing Cache store impementations > ------------------------------------------------------ > > Key: ISPN-5217 > URL: https://issues.jboss.org/browse/ISPN-5217 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores, Server > Reporter: Sebastian Łaskawiec > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5216) Create a quickstart or tutorial

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5216?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5216: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Create a quickstart or tutorial > ------------------------------- > > Key: ISPN-5216 > URL: https://issues.jboss.org/browse/ISPN-5216 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores, Server > Reporter: Sebastian Łaskawiec > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5339) Port improvements to Hibernate Search integration tests from the Hibernate Search codebase

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5339?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5339: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Port improvements to Hibernate Search integration tests from the Hibernate Search codebase > ------------------------------------------------------------------------------------------ > > Key: ISPN-5339 > URL: https://issues.jboss.org/browse/ISPN-5339 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Sanne Grinovero > Assignee: Davide D'Alto > Fix For: 8.0.0.Final > > > As a follow up on ISPN-5255, unfortunately we found some needed fixes in the Hibernate Search integration tests with the Infinispan Directory in the Hibernate Search codebase, just while we were migrating it to Infinispan. > I've rejected the PR as the module is to be considered "frozen" in Hibernate Search, we should see if there is something of value to be applied to the migrated tests: > https://github.com/hibernate/hibernate-search/pull/797#issuecomment-87802467 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5241) Cache topology updates should use the NO_FC flag

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5241?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5241: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Cache topology updates should use the NO_FC flag > ------------------------------------------------ > > Key: ISPN-5241 > URL: https://issues.jboss.org/browse/ISPN-5241 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.0.0.Final > > > Topology updates are sent while holding the ClusterCacheStatus lock, so they should never block. However, when MFC is present, the topology update can block waiting for enough credits. As most CacheTopologyControlCommands need to acquire the ClusterCacheStatus lock, this can easily lead to a full remote-executor pool (and OOB pool) and the appearance of a deadlock. > What's more, if one node is not responsive, it can block all the other nodes from receiving further topology updates. Topology updates should be as prompt as possible, so we should use the NO_FC flag to ensure that each node receives topology updates as soon as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5379: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-5379 > URL: https://issues.jboss.org/browse/ISPN-5379 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Final > > > From Dennis Reed: > A ConcurrentModificationException in the CacheWriter interceptor during a commit. > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953) > at java.util.LinkedList$ListItr.next(LinkedList.java:886) > at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210) > at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) > The code is looping through the modifications associated with the transaction: > List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications(); > ... > 210: for (WriteCommand cacheCommand : modifications) { > The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer". > But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification? > Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5367) Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5367?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5367: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Cache putMap/getAll usage of SegmentAwareMap/Set performance investigation > -------------------------------------------------------------------------- > > Key: ISPN-5367 > URL: https://issues.jboss.org/browse/ISPN-5367 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.Final > > > With the putAll method I introduced a SegmentAwareMap and SegmentAwareSet in thoughts that not copying all the elements would help performance. Thinking more it may be better to just make a new shallow copy map for each target instead. Need to do some testing to make sure if one is clearly better than the other. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5389) Optimize overlapping range and interval predicates (non-indexed query)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5389?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5389: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Optimize overlapping range and interval predicates (non-indexed query) > ---------------------------------------------------------------------- > > Key: ISPN-5389 > URL: https://issues.jboss.org/browse/ISPN-5389 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > > When a conjunction or disjunction contains several interval predicates for the same attribute we should attempt to reduce the number of predicates by exploiting eventual overlap. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5384) ReadCommittedEntry.isNull() always returns false

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5384?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5384: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > ReadCommittedEntry.isNull() always returns false > ------------------------------------------------ > > Key: ISPN-5384 > URL: https://issues.jboss.org/browse/ISPN-5384 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.0.Beta2, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Final > > > Should return {{value == null}}, just like {{RepeatableReadEntry}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5420) Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5420?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5420: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock > ------------------------------------------------------------------------------------------ > > Key: ISPN-5420 > URL: https://issues.jboss.org/browse/ISPN-5420 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.0.0.Final > > > The join process was designed in the idea that a node would start its caches in sequential order, so {{ClusterTopologyManager.waitForView()}} would block at most once for each joining node. However, WildFly actually starts {{2 * Runtime.availableProcessors()}} caches in parallel, and this can be a problem when the machine has a lot of cores and multiple nodes. > {{ClustertopologyManager.handleClusterView()}} only updates the {{viewId}} after it updated the cache topologies of each cache AND after it confirmed the availability of all the nodes with a {{POLICY_GET_STATUS}} RPC. This RPC can block, and it's very easy for the remote-executor thread pool on the coordinator to become overloades with threads like this: > {noformat} > "remote-thread-172" daemon prio=10 tid=0x00007f0cc48c0000 nid=0x28ca4 in Object.wait() [0x00007f0c5f25b000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at org.infinispan.topology.ClusterTopologyManagerImpl.waitForView(ClusterTopologyManagerImpl.java:357) > - locked <0x00000000ff3bd900> (a java.lang.Object) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:123) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:162) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:276) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5398) Run integration tests against WildFly 9.0.0.Beta2

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5398?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5398: ------------------------------ Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) > Run integration tests against WildFly 9.0.0.Beta2 > ------------------------------------------------- > > Key: ISPN-5398 > URL: https://issues.jboss.org/browse/ISPN-5398 > Project: Infinispan > Issue Type: Component Upgrade > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 7.2.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015