June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4401) OSGi - PAX-URL needs to work when the local mvn repo is passed from a configuration file

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4401?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4401: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2637 > OSGi - PAX-URL needs to work when the local mvn repo is passed from a configuration file > ---------------------------------------------------------------------------------------- > > Key: ISPN-4401 > URL: https://issues.jboss.org/browse/ISPN-4401 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > > Custom local repos can be defined in configuration files also in addition to passing -Dmaven.local.repo on the cmdline. > PAX-URL will fail to resolve mvn: URLs in this case. > Looking again at the maven properties available "localRepository" seems to cover both case. Use this instead of maven.repo.local. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4227) OSGi - import packages - don't hardcode version ranges

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4227?page=com.atlassian.jira.plugin.... ] Ion Savin closed ISPN-4227. --------------------------- > OSGi - import packages - don't hardcode version ranges > ------------------------------------------------------ > > Key: ISPN-4227 > URL: https://issues.jboss.org/browse/ISPN-4227 > Project: Infinispan > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Alpha5 > > > Version ranges in Import-Package declarations are hardcoded. Should specify them relative to the maven versions to avoid duplication / ease maintenance. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4380) ConfigurationParser don't work property in OSGi when exposed as services (annotations stripped)

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4380?page=com.atlassian.jira.plugin.... ] Ion Savin closed ISPN-4380. --------------------------- > ConfigurationParser don't work property in OSGi when exposed as services (annotations stripped) > ----------------------------------------------------------------------------------------------- > > Key: ISPN-4380 > URL: https://issues.jboss.org/browse/ISPN-4380 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Alpha5 > > > ConfigurationParsers use runtime annotations: @Namespace @Namespaces. > If the parsers are exposed as services in OSGi the annotations are lost because the container will return instances of proxy classes which don't have these annotations. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4400) Initial state transfer with large number of segments is very slow

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4400: ------------------------------------- Summary: Initial state transfer with large number of segments is very slow Key: ISPN-4400 URL: https://issues.jboss.org/browse/ISPN-4400 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core, State Transfer Affects Versions: 7.0.0.Alpha4 Reporter: Tristan Tarrant Assignee: Adrian Nistor Fix For: 7.0.0.Final StateTransfer performance is O(n²) based on the number of segments -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4400) Initial state transfer with large number of segments is very slow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4400?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4400: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1108451 > Initial state transfer with large number of segments is very slow > ----------------------------------------------------------------- > > Key: ISPN-4400 > URL: https://issues.jboss.org/browse/ISPN-4400 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 7.0.0.Final > > > StateTransfer performance is O(n²) based on the number of segments -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4395) Query tests slow

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4395?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4395: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done Integrated in master. Thanks Gustavo! > Query tests slow > ---------------- > > Key: ISPN-4395 > URL: https://issues.jboss.org/browse/ISPN-4395 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Query > Affects Versions: 7.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Alpha5 > > > Mailing list discussion: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015062.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4385) Document installation process for OSGi containers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4385?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4385: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1067725 > Document installation process for OSGi containers > ------------------------------------------------- > > Key: ISPN-4385 > URL: https://issues.jboss.org/browse/ISPN-4385 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4375) EntryIterable need not throw an exception on close()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4375?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-4375: ------------------------------- Description: Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api. In fact, none of the methods called from within the implemention's close() method throws a checked exception, so why should the close() method on the interface? (was: Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api.) > EntryIterable need not throw an exception on close() > ---------------------------------------------------- > > Key: ISPN-4375 > URL: https://issues.jboss.org/browse/ISPN-4375 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api. In fact, none of the methods called from within the implemention's close() method throws a checked exception, so why should the close() method on the interface? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4310) StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4310?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4310: ----------------------------------------------- Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1104031|https://bugzilla.redhat.com/show_bug.cgi?id=1104031] from POST to MODIFIED > StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST > ----------------------------------------------------------------------------------------- > > Key: ISPN-4310 > URL: https://issues.jboss.org/browse/ISPN-4310 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 63gablocker > Fix For: 7.0.0.Alpha5 > > > 1. A requests segment from B (there are multiple chunks) > 2. B sends all chunks, but before A receives them, new topology arrives and A cancels the ST. > 3. Another topology comes and A requests this segment again > 4. A receives the old StateResponseCommand with lastChunk=true and thinks that it got all segments, therefore, it discards further chunks. > Result is inconsistent cluster, and after further rebalances completely lost data. > This ought to be rare, but was repeatedly observed when gracefully stopping coordinator on a 32-node cluster full of data. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on ISPN-4291: ----------------------------------- Yeah, there may still be room for optimization here. Two use cases: - node joining the cluster It cannot be skipped here, as there may be stale data in the cache store which can only be determined by looking through it all. (this was the main use case I was looking at). - later state transfers Here it could be skipped if no segments are lost (I.E. repl) > Poor REPL state transfer performance with cache stores > ------------------------------------------------------ > > Key: ISPN-4291 > URL: https://issues.jboss.org/browse/ISPN-4291 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > > During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node. > This is an extremely slow operation, and doesn't even make sense for a REPL cache. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 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 June 2014