August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4166) useSynchronization should be disabled by default

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4166?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4166: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > useSynchronization should be disabled by default > ------------------------------------------------ > > Key: ISPN-4166 > URL: https://issues.jboss.org/browse/ISPN-4166 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Configuration, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Ion Savin > Priority: Critical > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > When Infinispan registers with the transaction manager as a synchronization, failures during commit are not reported to the user. > Even if registering as a synchronization is faster in some cases, the default should be the safe version. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4262) Rolling back a transaction after commit timeout should release locks in two phases

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4262?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4262: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Rolling back a transaction after commit timeout should release locks in two phases > ---------------------------------------------------------------------------------- > > Key: ISPN-4262 > URL: https://issues.jboss.org/browse/ISPN-4262 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Beta2 > > > This is related to ISPN-4137. > When a commit command times out, we send a rollback command to release locks. The problem is that the node that timed out might still execute commit command, before the rollback command reaching the backup but after it released the locks on the primary owner. > The solution is to not release any locks during the rollback command's execution, but send an asynchronous TxCompletionNotification afterwards - just like for commit commands. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4193) StateSequencer: state machine-based utility for synchronizing multi-threaded tests

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4193?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4193: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > StateSequencer: state machine-based utility for synchronizing multi-threaded tests > ---------------------------------------------------------------------------------- > > Key: ISPN-4193 > URL: https://issues.jboss.org/browse/ISPN-4193 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Beta2 > > > I've previously written a {{CheckPoint}} class for the same purpose, but while the logs are a little clearer, it's still pretty hard to reason about the expected ordering of events with a CheckPoint-based test. > StateSequencer-based tests should make it clear what the expected order of states should be from the beginning of the test: > {code:java} > sequencer.logicalThread("t1", "t1:block", "t1:resume"); > sequencer.logicalThread("t2", "t2:do_stuff"); > sequencer.order("t1:block", "t2:do_stuff", "t1:resume"); > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4190: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList > ------------------------------------------------------------------------- > > Key: ISPN-4190 > URL: https://issues.jboss.org/browse/ISPN-4190 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Beta2 > > > We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self. > JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4226) SearchManagerImpl use a bad entity names resolver

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4226?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4226: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > SearchManagerImpl use a bad entity names resolver > ------------------------------------------------- > > Key: ISPN-4226 > URL: https://issues.jboss.org/browse/ISPN-4226 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 6.0.2.Final > Environment: Wildfly 8.1.0 CR1 > Reporter: David Cabillic > Assignee: Sanne Grinovero > Labels: 64QueryBlockers > Fix For: 7.0.0.Beta2 > > > Inner class org.infinispan.query.impl.SearchManagerImpl$EntityNamesResolver used in method SearchManagerImpl#getQueryFactory use Class.forName(String) instead of Thread.currentThread().getContextClassLoader().loadClass(String) > It is a problem if @Indexed classes are in an EAR/WAR which is not loaded in the same ClassLoader. It works great with ContextClassLoader. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4340) Automatically setup shared indexes when indexing is enabled

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4340?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4340: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Automatically setup shared indexes when indexing is enabled > ----------------------------------------------------------- > > Key: ISPN-4340 > URL: https://issues.jboss.org/browse/ISPN-4340 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Labels: 64QueryBlockers > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > - on replicated Caches, we should create a default index on a FSDirectory and provide some appropriate default tuning, for example enabling NRT. > - distributed Caches will need the Infinispan Directory (shared) and a master/slave backend (Infinispan IndexManager, while NRT is not compatible in this case) > We want to keep the properties configuration structure as well as an "advanced tuning" and override capabilities of the default choices. > Some more common options like sync/async indexing should probably be promoted to be controlled by the XML elements and configuration DSL excplicitly. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4289) Provide a user friendly error for not being able to parse 6.0 configuration files

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4289?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4289: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Provide a user friendly error for not being able to parse 6.0 configuration files > --------------------------------------------------------------------------------- > > Key: ISPN-4289 > URL: https://issues.jboss.org/browse/ISPN-4289 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > When failing to parse a configuration file in XML format from Infinispan 6.0 (apparently now unsupported) the error message should be improved. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4398) Hot Rod server event results in connection/class leak

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4398?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4398: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Hot Rod server event results in connection/class leak > ----------------------------------------------------- > > Key: ISPN-4398 > URL: https://issues.jboss.org/browse/ISPN-4398 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > On linux systems, running Hot Rod server testsuite results in {code}Caused by: java.io.IOException: Too many open files{code} errors. These were introduced when remote events was integrated. > There's a leak when listener is removed, the eventSenders in ClientListenerRegistry is not updated to remove it. The channel should be closed client side. Needs investigating further. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4390: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > CHMv8 leaks ThreadLocal > ----------------------- > > Key: ISPN-4390 > URL: https://issues.jboss.org/browse/ISPN-4390 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Fix For: 7.0.0.Beta2 > > > As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4377) Make receiving state for Hot Rod client listeners optional

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4377?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4377: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Make receiving state for Hot Rod client listeners optional > ---------------------------------------------------------- > > Key: ISPN-4377 > URL: https://issues.jboss.org/browse/ISPN-4377 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > Receiving state for Hot Rod client listeners has a cost. Some users might not want to incur it, so it should be optional. By default, it should be enabled though for correctness. -- 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