July 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9343) Streams should skip loader when preload=true and eviction is not enabled

by William Burns (JIRA)

William Burns created ISPN-9343: ----------------------------------- Summary: Streams should skip loader when preload=true and eviction is not enabled Key: ISPN-9343 URL: https://issues.jboss.org/browse/ISPN-9343 Project: Infinispan Issue Type: Enhancement Affects Versions: 9.3.0.Final Reporter: William Burns Currently stream operations and other bulk operations always read from the loader to ensure they don't miss any entries. However when a cache is configured to have preload=true and eviction is not enabled we should be able to ignore the loader and use in memory only. This would improve the performance of streams substantially in these cases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8844: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.4.0.Alpha1 9.4.0.Final Resolution: Done > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Dan Berindei > Fix For: 9.4.0.Alpha1, 9.4.0.Final > > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9320) Automatic hot rod client version selection

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9320?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-9320: --------------------------------------- I'd also like to see a decoupling of protocol version from available ops: * return the recognized ops as a response to PING as a list (e.g. SMTP does this in response to EHLO requests) * version the ops, e.g. if we make incompatible changes to PUT we introduce PUT2 with dedicated ops > Automatic hot rod client version selection > ------------------------------------------ > > Key: ISPN-9320 > URL: https://issues.jboss.org/browse/ISPN-9320 > Project: Infinispan > Issue Type: Feature Request > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 9.4.0.Final > > > A HotRod client should be able to automatic detect the server version and downgrade the protocol version if the server is older. > Older HotRod clients are still able to connect to newer servers. > It would be helpful if new API functions are rejected with a clear error message that the function is not available if using an old protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9320) Automatic hot rod client version selection

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9320?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-9320: --------------------------------------- Proposal: the client should start from the highest version it supports and sends PING requests decrementing the version in the header until it receives a valid PING response from the server. The server doesn't currently validate the version in the header (it just checks whether it is >=20 to enable the 2.x decoder). > Automatic hot rod client version selection > ------------------------------------------ > > Key: ISPN-9320 > URL: https://issues.jboss.org/browse/ISPN-9320 > Project: Infinispan > Issue Type: Feature Request > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 9.4.0.Final > > > A HotRod client should be able to automatic detect the server version and downgrade the protocol version if the server is older. > Older HotRod clients are still able to connect to newer servers. > It would be helpful if new API functions are rejected with a clear error message that the function is not available if using an old protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9342) Lock timeout when writing to index caches for the first time

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-9342: --------------------------------------- Summary: Lock timeout when writing to index caches for the first time Key: ISPN-9342 URL: https://issues.jboss.org/browse/ISPN-9342 Project: Infinispan Issue Type: Bug Components: Embedded Querying, Remote Querying Affects Versions: 9.3.0.Final Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes If multiple puts are done concurrently for the first time in an indexed cache, the QueryInterceptor will bottleneck in the entity class internal registration, causing Timeout exceptions -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9320) Automatic hot rod client version selection

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9320?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9320: ---------------------------------- Security: (was: Red Hat Internal) > Automatic hot rod client version selection > ------------------------------------------ > > Key: ISPN-9320 > URL: https://issues.jboss.org/browse/ISPN-9320 > Project: Infinispan > Issue Type: Feature Request > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 9.4.0.Final > > > A HotRod client should be able to automatic detect the server version and downgrade the protocol version if the server is older. > Older HotRod clients are still able to connect to newer servers. > It would be helpful if new API functions are rejected with a clear error message that the function is not available if using an old protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-63) writeObject throws IllegalArgumentException with oneof label

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/IPROTO-63?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated IPROTO-63: ------------------------------- Description: The below schema results in the following exception: Schema: {code:java} message EntryVersion { oneof version { NumericVersion numeric = 1; ClusteredVersion clustered = 2; } // optional NumericVersion numeric = 1; // optional ClusteredVersion clustered = 2; } message NumericVersion { required int64 version = 1; } message ClusteredVersion { required int64 version = 1; required int32 topology = 2; } {code} Exception: {code:java} java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric {code} It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...]. If the oneof label is replaced with the commented optional fields, the marshallers work as expected. was: The below schema results in the following exception: Schema: {code:java} message EntryVersion { oneof version { NumericVersion numeric = 1; ClusteredVersion clustered = 2; } // optional NumericVersion numeric = 1; // optional ClusteredVersion clustered = 2; } message NumericVersion { required int64 version = 1; } message ClusteredVersion { required int64 version = 1; required int32 topology = 2; } {code} Exception: {code:java} java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric {code} It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...]. > writeObject throws IllegalArgumentException with oneof label > ------------------------------------------------------------ > > Key: IPROTO-63 > URL: https://issues.jboss.org/browse/IPROTO-63 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > > The below schema results in the following exception: > Schema: > {code:java} > message EntryVersion { > oneof version { > NumericVersion numeric = 1; > ClusteredVersion clustered = 2; > } > // optional NumericVersion numeric = 1; > // optional ClusteredVersion clustered = 2; > } > message NumericVersion { > required int64 version = 1; > } > message ClusteredVersion { > required int64 version = 1; > required int32 topology = 2; > } > {code} > Exception: > {code:java} > java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric > {code} > It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...]. > If the oneof label is replaced with the commented optional fields, the marshallers work as expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-63) writeObject throws IllegalArgumentException with oneof label

by Ryan Emerson (JIRA)

Ryan Emerson created IPROTO-63: ---------------------------------- Summary: writeObject throws IllegalArgumentException with oneof label Key: IPROTO-63 URL: https://issues.jboss.org/browse/IPROTO-63 Project: Infinispan ProtoStream Issue Type: Bug Reporter: Ryan Emerson The below schema results in the following exception: Schema: {code:java} message EntryVersion { oneof version { NumericVersion numeric = 1; ClusteredVersion clustered = 2; } // optional NumericVersion numeric = 1; // optional ClusteredVersion clustered = 2; } message NumericVersion { required int64 version = 1; } message ClusteredVersion { required int64 version = 1; required int32 topology = 2; } {code} Exception: {code:java} java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric {code} It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8844: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6113 > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Dan Berindei > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8844: ---------------------------------- Status: Open (was: New) > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Dan Berindei > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 July 2018