July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4264) CLI should be able to manipulate role mapping

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4264?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4264: ----------------------------------------------- Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1109583|https://bugzilla.redhat.com/show_bug.cgi?id=1109583] from ASSIGNED to VERIFIED > CLI should be able to manipulate role mapping > --------------------------------------------- > > Key: ISPN-4264 > URL: https://issues.jboss.org/browse/ISPN-4264 > Project: Infinispan > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core, Remote Protocols, Security, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > The server CLI should have "grant" and "deny" commands to manipulate the role mapping: > [GRANT|DENY] role TO principal [ON container]? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4291: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1111188|https://bugzilla.redhat.com/show_bug.cgi?id=1111188] from ON_QA to VERIFIED > 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 > Fix For: 7.0.0.Alpha5 > > > 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)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3936) State transfer should not modify or iterate shared cache stores

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3936?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3936: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1113259|https://bugzilla.redhat.com/show_bug.cgi?id=1113259] from ON_QA to VERIFIED > State transfer should not modify or iterate shared cache stores > --------------------------------------------------------------- > > Key: ISPN-3936 > URL: https://issues.jboss.org/browse/ISPN-3936 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > When installing a new topology, we invalidate the cache entries that are no longer mapped to the local node. We also iterate over the entries in the cache stores and delete the ones that are no longer local, but this should only happen if the cache store is not shared. > We had similar issues in the past, but this seems to be related to the new cache store API introduced in 6.0. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4475) Test indexless query in compat mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4475?page=com.atlassian.jira.plugin.... ] Work on ISPN-4475 started by Adrian Nistor. > Test indexless query in compat mode > ----------------------------------- > > Key: ISPN-4475 > URL: https://issues.jboss.org/browse/ISPN-4475 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4484) Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4484?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4484: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104045 > Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command > ------------------------------------------------------------------------ > > Key: ISPN-4484 > URL: https://issues.jboss.org/browse/ISPN-4484 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > This appeared during the 32-nodes elasticity test in the Hyperion environment. > Just as apex947 left, it started a rebalance, which apex948 dutifully cancelled as it became the new coordinator. apex949 had already requested segments from apex959, so it sent a StateRequestCommand(CANCEL_STATE_TRANSFER) asynchronously to apex959. Then apex948 started a new rebalance, and apex949 asked apex959 for the same segments. When apex959 finally received the cancel request, it didn't check the topology id and it incorrectly cancelled the outbound transfer to apex949. > The solution would be to verify the topology id in the CANCEL_STATE_TRANSFER command before cancelling the transfer. I also think we can avoid sending the cancel command completely in this case, and only send it as we are about to stop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4484) Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4484: ---------------------------------- Summary: Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command Key: ISPN-4484 URL: https://issues.jboss.org/browse/ISPN-4484 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core, State Transfer Affects Versions: 6.0.2.Final Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 7.0.0.Alpha5 This appeared during the 32-nodes elasticity test in the Hyperion environment. Just as apex947 left, it started a rebalance, which apex948 dutifully cancelled as it became the new coordinator. apex949 had already requested segments from apex959, so it sent a StateRequestCommand(CANCEL_STATE_TRANSFER) asynchronously to apex959. Then apex948 started a new rebalance, and apex949 asked apex959 for the same segments. When apex959 finally received the cancel request, it didn't check the topology id and it incorrectly cancelled the outbound transfer to apex949. The solution would be to verify the topology id in the CANCEL_STATE_TRANSFER command before cancelling the transfer. I also think we can avoid sending the cancel command completely in this case, and only send it as we are about to stop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2454) The current SQL query that checks table existence is under optimized on big database

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2454?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2454: ----------------------------------------------- Jitka Kozana <jkudrnac(a)redhat.com> changed the Status of [bug 1087236|https://bugzilla.redhat.com/show_bug.cgi?id=1087236] from NEW to CLOSED > The current SQL query that checks table existence is under optimized on big database > ------------------------------------------------------------------------------------ > > Key: ISPN-2454 > URL: https://issues.jboss.org/browse/ISPN-2454 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 5.1.0.FINAL > Reporter: Nicolas Filotto > Assignee: Tristan Tarrant > Labels: jdg, jdg6 > Fix For: 5.2.0.Beta4 > > > Last year I proposed an enhancement allowing to use the implicit db schema to ease life of end-user, unfortunately it seems that it affects the startup time of the product when the tables contain a lot of rows. Indeed the query can take several seconds to return a result. > The idea of this task would be to optimize this query for all supported databases in order to avoid this drawback. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4467) keySet operation via HotRod in compatibility mode throws ClassCastException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4467?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4467: -------------------------------- Fix Version/s: 7.0.0.Final > keySet operation via HotRod in compatibility mode throws ClassCastException > --------------------------------------------------------------------------- > > Key: ISPN-4467 > URL: https://issues.jboss.org/browse/ISPN-4467 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > The HotRod client's keySet() operation throws ClassCastException due to the following reason: > When Encoder2x.scala in its writeResponse() method decodes the operation as BulkGetKeysResponse, it runs a Map/Reduce job that returns a set of keys in the whole cluster. > The operation returns a set of "unmarshalled" (cos we're in compatibility mode) entries. However, Scala infers the type of individual entries as "Bytes" which is an alias for Array[Byte]. > As a result, when this iterator from this key set is retrieved, it is not possible to iterate through the entries because Scala automatically tries to convert each (unmarshalled) entry into a byte array, which results in the exception. > This line results in throwing CCE: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4467) keySet operation via HotRod in compatibility mode throws ClassCastException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4467?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4467: -------------------------------- Fix Version/s: (was: 7.0.0.Final) > keySet operation via HotRod in compatibility mode throws ClassCastException > --------------------------------------------------------------------------- > > Key: ISPN-4467 > URL: https://issues.jboss.org/browse/ISPN-4467 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > The HotRod client's keySet() operation throws ClassCastException due to the following reason: > When Encoder2x.scala in its writeResponse() method decodes the operation as BulkGetKeysResponse, it runs a Map/Reduce job that returns a set of keys in the whole cluster. > The operation returns a set of "unmarshalled" (cos we're in compatibility mode) entries. However, Scala infers the type of individual entries as "Bytes" which is an alias for Array[Byte]. > As a result, when this iterator from this key set is retrieved, it is not possible to iterate through the entries because Scala automatically tries to convert each (unmarshalled) entry into a byte array, which results in the exception. > This line results in throwing CCE: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4467) keySet operation via HotRod in compatibility mode throws ClassCastException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4467?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4467: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > keySet operation via HotRod in compatibility mode throws ClassCastException > --------------------------------------------------------------------------- > > Key: ISPN-4467 > URL: https://issues.jboss.org/browse/ISPN-4467 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > The HotRod client's keySet() operation throws ClassCastException due to the following reason: > When Encoder2x.scala in its writeResponse() method decodes the operation as BulkGetKeysResponse, it runs a Map/Reduce job that returns a set of keys in the whole cluster. > The operation returns a set of "unmarshalled" (cos we're in compatibility mode) entries. However, Scala infers the type of individual entries as "Bytes" which is an alias for Array[Byte]. > As a result, when this iterator from this key set is retrieved, it is not possible to iterate through the entries because Scala automatically tries to convert each (unmarshalled) entry into a byte array, which results in the exception. > This line results in throwing CCE: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014