February 2018 - infinispan-issues

[JBoss JIRA] (ISPN-8799) Limit the default number of shards in the AffinityIndexManager

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8799?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8799: ------------------------------------ Description: By default this index manager will create as many Lucene indexes as Infinispan segments (256) which will penalize query performance. (was: By default this index manager will create as many Lucene indexes and Infinispan segments (256) which will penalize query performance.) > Limit the default number of shards in the AffinityIndexManager > -------------------------------------------------------------- > > Key: ISPN-8799 > URL: https://issues.jboss.org/browse/ISPN-8799 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Final > > > By default this index manager will create as many Lucene indexes as Infinispan segments (256) which will penalize query performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8798) ByteString places too strict a constraint on cache name length

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-8798?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-8798: ------------------------------- Description: The hibernate 2nd level cache code can easily generate cache names that exceed the byte length restriction enforced by ByteString. Cache names are generated using the fully qualified class name of the entity, which are user defined, and in the case of WildFly, also includes the deployment name, which can be particularly long for EARs. At the very least, we should use an unsigned byte which doubles the allowed size. Why not also consider using https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... to marshal/unmarshal the size of the byte[] containing the name? At worst, this costs an extra byte, but solves the size problem for even sizes larger than 255. was: The hibernate 2nd level cache code can easily generate cache names that exceed the byte length restriction enforced by ByteString. Cache names are generated using the fully qualified class name of the entity, which are user defined, and in the case of WildFly, also includes the deployment name, which can be particularly long for EARs. Why not instead use https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... to marshal/unmarshal the size of the byte[] containing the name? At worst, this costs an extra byte, but solves the size problem. > ByteString places too strict a constraint on cache name length > -------------------------------------------------------------- > > Key: ISPN-8798 > URL: https://issues.jboss.org/browse/ISPN-8798 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.5.Final, 9.2.0.CR2 > Reporter: Paul Ferraro > Priority: Blocker > > The hibernate 2nd level cache code can easily generate cache names that exceed the byte length restriction enforced by ByteString. Cache names are generated using the fully qualified class name of the entity, which are user defined, and in the case of WildFly, also includes the deployment name, which can be particularly long for EARs. > At the very least, we should use an unsigned byte which doubles the allowed size. Why not also consider using https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... to marshal/unmarshal the size of the byte[] containing the name? At worst, this costs an extra byte, but solves the size problem for even sizes larger than 255. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8798) ByteString places too strict a constraint on cache name length

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-8798: ---------------------------------- Summary: ByteString places too strict a constraint on cache name length Key: ISPN-8798 URL: https://issues.jboss.org/browse/ISPN-8798 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.2.0.CR2, 9.1.5.Final Reporter: Paul Ferraro Priority: Blocker The hibernate 2nd level cache code can easily generate cache names that exceed the byte length restriction enforced by ByteString. Cache names are generated using the fully qualified class name of the entity, which are user defined, and in the case of WildFly, also includes the deployment name, which can be particularly long for EARs. Why not instead use https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... to marshal/unmarshal the size of the byte[] containing the name? At worst, this costs an extra byte, but solves the size problem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7566) ByteString.readObject() throws NegativeArraySizeException when length > 127

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-7566?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-7566: ------------------------------------ Is the enforcement of a byte length really necessary? The hibernate 2nd level cache code can easily generate cache names with byte arrays larger than 127. Why not instead use https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... ? > ByteString.readObject() throws NegativeArraySizeException when length > 127 > --------------------------------------------------------------------------- > > Key: ISPN-7566 > URL: https://issues.jboss.org/browse/ISPN-7566 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.CR3 > > > We don't expect or recommend cache names this big, but we should fail at the time the `ByteString` is created and not at the time it is read by a remote node. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8797) Administration console - Counters tab - reset counter operation: doesn't work

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8797?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8797: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/231 > Administration console - Counters tab - reset counter operation: doesn't work > ----------------------------------------------------------------------------- > > Key: ISPN-8797 > URL: https://issues.jboss.org/browse/ISPN-8797 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.2.0.CR2 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > > Reset counter button doesn't work. No errors shown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8797) Administration console - Counters tab - reset counter operation: doesn't work

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8797?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8797: -------------------------------------- Status: Open (was: New) > Administration console - Counters tab - reset counter operation: doesn't work > ----------------------------------------------------------------------------- > > Key: ISPN-8797 > URL: https://issues.jboss.org/browse/ISPN-8797 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.2.0.CR2 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > > Reset counter button doesn't work. No errors shown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8797) Administration console - Counters tab - reset counter operation: doesn't work

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8797?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic moved JDG-1546 to ISPN-8797: ------------------------------------------------ Project: Infinispan (was: JBoss Data Grid) Key: ISPN-8797 (was: JDG-1546) Workflow: GIT Pull Request with Triage workflow (was: CDW with loose statuses v1) Component/s: Console (was: Management and Monitoring) Affects Version/s: 9.2.0.CR2 (was: JDG 7.2 ER2) > Administration console - Counters tab - reset counter operation: doesn't work > ----------------------------------------------------------------------------- > > Key: ISPN-8797 > URL: https://issues.jboss.org/browse/ISPN-8797 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.2.0.CR2 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > > Reset counter button doesn't work. No errors shown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8795) Administration console - Create new counter dialog: error when fill only mandatory fields.

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8795?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8795: -------------------------------------- Status: Open (was: New) > Administration console - Create new counter dialog: error when fill only mandatory fields. > ------------------------------------------------------------------------------------------ > > Key: ISPN-8795 > URL: https://issues.jboss.org/browse/ISPN-8795 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.2.0.CR2 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > > *Actual:* > In the creation counter dialog only 'Name' field marked as mandatory but error appears requiring to select Storage type also. > Error: WFLYCTL0172: storage is required > *Expected:* > Some type of storage selected by default. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8795) Administration console - Create new counter dialog: error when fill only mandatory fields.

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8795?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8795: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/230 > Administration console - Create new counter dialog: error when fill only mandatory fields. > ------------------------------------------------------------------------------------------ > > Key: ISPN-8795 > URL: https://issues.jboss.org/browse/ISPN-8795 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.2.0.CR2 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > > *Actual:* > In the creation counter dialog only 'Name' field marked as mandatory but error appears requiring to select Storage type also. > Error: WFLYCTL0172: storage is required > *Expected:* > Some type of storage selected by default. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8792) EntryWrappingInterceptorDoesNotBlockTest random failures

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8792?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-8792: ------------------------------ Description: PrepareExpectingInterceptor (at the top of the stack) expects that the invocationstage is receives is not complete. When a remote get is completed before the interceptor gets the stage, the stage can get completed, too, and an assertion fires. Subsequently the latch in the interceptor is not decremented and {{await}} throws a TimeoutException, failing the test. > EntryWrappingInterceptorDoesNotBlockTest random failures > -------------------------------------------------------- > > Key: ISPN-8792 > URL: https://issues.jboss.org/browse/ISPN-8792 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.CR2 > Reporter: Radim Vansa > Assignee: Radim Vansa > > PrepareExpectingInterceptor (at the top of the stack) expects that the invocationstage is receives is not complete. When a remote get is completed before the interceptor gets the stage, the stage can get completed, too, and an assertion fires. > Subsequently the latch in the interceptor is not decremented and {{await}} throws a TimeoutException, failing the test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2018