November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5015) Update 2LC docu with CacheKey type support in clustered environments

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5015: -------------------------------------- Summary: Update 2LC docu with CacheKey type support in clustered environments Key: ISPN-5015 URL: https://issues.jboss.org/browse/ISPN-5015 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreño Depending on the cache key used, session factory name might have to be locked to a particular name across the cluster. All info available in the forum links. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4969) Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4969?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4969: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1163820|https://bugzilla.redhat.com/show_bug.cgi?id=1163820] from MODIFIED to ON_QA > Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4969 > URL: https://issues.jboss.org/browse/ISPN-4969 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.8.Final, 6.0.2.Final, 7.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 7.0.1.Final, 5.2.9.Final, 6.0.3.Final > > > We've had several reports in the WildFly forums of application runtime failures following undeployment of a separate application. > WF creates a cache instance for each web application within the same cache container. However, KeyAffinityServiceImpl registers a cache manager listener that calls stop() on a @CacheStoppedEvent. However, this event might be triggered by any cache, not necessarily the cache with to which the KeyAffinityService is associated. > The KeyAffinityServiceImpl.handleCacheStopped(CacheStoppedEvent) should only call stop() if the event.getCacheName() equals the name of the cache to which the affinity service is associated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5014) Remove "clean" goal trigger from the "prepare-package" phase of all/*

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5014?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5014: ---------------------------- Status: Open (was: New) > Remove "clean" goal trigger from the "prepare-package" phase of all/* > --------------------------------------------------------------------- > > Key: ISPN-5014 > URL: https://issues.jboss.org/browse/ISPN-5014 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.2.Final > Reporter: Ion Savin > Assignee: Ion Savin > > To resolve ISPN-4939 a "clean" goal was attached to the "prepare-package" phase. > This fix is not appropriate in combination with ISPN-4942 (uberjars in OSGi) as needed resources are created before this phase ("initialize" is not appropriate as a clean will be triggered when the distribution module prepares the javadoc and before the uberjars are added to the distribution package). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5014) Remove "clean" goal trigger from the "prepare-package" phase of all/*

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5014?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5014: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3102 > Remove "clean" goal trigger from the "prepare-package" phase of all/* > --------------------------------------------------------------------- > > Key: ISPN-5014 > URL: https://issues.jboss.org/browse/ISPN-5014 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.2.Final > Reporter: Ion Savin > Assignee: Ion Savin > > To resolve ISPN-4939 a "clean" goal was attached to the "prepare-package" phase. > This fix is not appropriate in combination with ISPN-4942 (uberjars in OSGi) as needed resources are created before this phase ("initialize" is not appropriate as a clean will be triggered when the distribution module prepares the javadoc and before the uberjars are added to the distribution package). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5014) Remove "clean" goal trigger from the "prepare-package" phase of all/*

by Ion Savin (JIRA)

Ion Savin created ISPN-5014: ------------------------------- Summary: Remove "clean" goal trigger from the "prepare-package" phase of all/* Key: ISPN-5014 URL: https://issues.jboss.org/browse/ISPN-5014 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 7.0.2.Final Reporter: Ion Savin Assignee: Ion Savin To resolve ISPN-4939 a "clean" goal was attached to the "prepare-package" phase. This fix is not appropriate in combination with ISPN-4942 (uberjars in OSGi) as needed resources are created before this phase ("initialize" is not appropriate as a clean will be triggered when the distribution module prepares the javadoc and before the uberjars are added to the distribution package). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4807) NPE under high load when using async metadata writes for the Lucene Directory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4807?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4807: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167469 > NPE under high load when using async metadata writes for the Lucene Directory > ----------------------------------------------------------------------------- > > Key: ISPN-4807 > URL: https://issues.jboss.org/browse/ISPN-4807 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.CR2 > > > Method > org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.deleteOrReleaseReadLock(String) > might hit a NPE under high load as the fileMetadata retrieved from the Cache might be null when it's written asynchronously. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4611) Explore ability to use Put-Async in some operations on the Lucene Directory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4611?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4611: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167469 > Explore ability to use Put-Async in some operations on the Lucene Directory > --------------------------------------------------------------------------- > > Key: ISPN-4611 > URL: https://issues.jboss.org/browse/ISPN-4611 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.CR1 > > Attachments: 0001-ISPN-4611-Update-write-operations-on-the-list-of-def.patch > > > I just noticed that if I change all put operations in FileListOperations to be putAsync, the stress tests against index corruption and parallel queries run flawlessly. > It's possible that these particular operation might not need the synchronous flush, but we need to verify if a committed index change is immediately visible to queries. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4605) Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4605?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4605: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1135924, https://bugzilla.redhat.com/show_bug.cgi?id=1139651, https://bugzilla.redhat.com/show_bug.cgi?id=1167469 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1135924, https://bugzilla.redhat.com/show_bug.cgi?id=1139651) > Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4605 > URL: https://issues.jboss.org/browse/ISPN-4605 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 7.0.0.Alpha5 > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta1 > > > Some components in the Lucene Directory are highly concurrent, when these are marshalled we need to ensure a consistent snapshot is written to the byte stream. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4708) Make DirectoryImplementor#deleteFile apply changes asynchronously

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4708?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4708: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167469 > Make DirectoryImplementor#deleteFile apply changes asynchronously > ----------------------------------------------------------------- > > Key: ISPN-4708 > URL: https://issues.jboss.org/browse/ISPN-4708 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.CR2 > > > Looks like the {{deleteFile}} operation is the main responsible component for the latency generated by writing to the Lucene Directory, but this operation could be processed asynchronously by a background thread. > Configurtion API {{org.infinispan.lucene.directory.BuildContext}} could allow for an optional Executor to be passed for this purpose, and if there isn't we keep current behaviour for running it synchronously. > The tricky part I guess is making sure that the tests, which verify written consistency -including delete operations - are refactored to be able to deal with the fact that delete operations will happen eventually. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4994) MultiHotRodServerIspnDirReplQueryTest fails consistently

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4994?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-4994: --------------------------------------- For the record, I had this problem again today while testing master at {{e205ff7}}. But I had it only once, re-running the testsuite it seems to be ok most of the time. @anistor are you confident that rolling back those commits it would _never_ fail? Just wondering, as this JIRA description sais it fails "consistently" but that's not my experience so this could be misleading. > MultiHotRodServerIspnDirReplQueryTest fails consistently > -------------------------------------------------------- > > Key: ISPN-4994 > URL: https://issues.jboss.org/browse/ISPN-4994 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 7.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > See failure in CI ere: http://ci.infinispan.org/viewLog.html?buildId=14226&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 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 November 2014