June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11851) FD_SOCK should use the same bind address as TCP

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11851?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11851: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > FD_SOCK should use the same bind address as TCP > ----------------------------------------------- > > Key: ISPN-11851 > URL: https://issues.redhat.com/browse/ISPN-11851 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.0.Dev05, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.2.Final > > > In the JGroups configuration files we ship, we use a different default for {{TCP.bind_addr}} and {{UDP.bind_addr}} than JGroups does. > {code:xml} > <TCP bind_addr="${jgroups.bind.address,jgroups.tcp.address:SITE_LOCAL}"/> > <UDP bind_addr="${jgroups.bind.address,jgroups.udp.address:SITE_LOCAL}"/> > {code} > However, we didn't change the default for {{FD_SOCK}}, so it uses the JGroups default: -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11632) Address comments in ISPN-10457

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11632?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11632: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Address comments in ISPN-10457 > ------------------------------ > > Key: ISPN-11632 > URL: https://issues.redhat.com/browse/ISPN-11632 > Project: Infinispan > Issue Type: Task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.2.Final > > > There were some late comments in https://github.com/infinispan/infinispan/pull/8096 that we can still address. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11585) Use JavaSerializationMarshaller in jcache TCK modules

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11585?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11585: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Use JavaSerializationMarshaller in jcache TCK modules > ----------------------------------------------------- > > Key: ISPN-11585 > URL: https://issues.redhat.com/browse/ISPN-11585 > Project: Infinispan > Issue Type: Task > Components: JCache > Affects Versions: 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.2.Final > > > We should run the JSR-107 TCK with the java serialization marshaller, not with the protostream marshaller, to ensure that Infinispan is usable as a JCache implementation with minimal application code changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11304) Allow scaling up without state transfer

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11304?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11304: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Allow scaling up without state transfer > --------------------------------------- > > Key: ISPN-11304 > URL: https://issues.redhat.com/browse/ISPN-11304 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.2.Final > > > We should allow a cache to scale up without performing any state transfer, but without losing the data. > To simplify things, the initial version will support a single owner, and will assume that only one node is being added at a time. > The cache must be accessible remotely, but since information about the location of the keys is not accessible from the client, the client is expected to ignore ownership and use a round-robin access strategy. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11279) Replace UUID.randomUUID() with Util.threadLocalRandomUUID()

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11279?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11279: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Replace UUID.randomUUID() with Util.threadLocalRandomUUID() > ----------------------------------------------------------- > > Key: ISPN-11279 > URL: https://issues.redhat.com/browse/ISPN-11279 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.2.Final > > > {{UUID.randomUUID()}} is pretty expensive, because it uses {{SecureRandom}}. > We don't need cryptographically strong UUIDs, so we can generate all our UUIDs with {{Util.threadLocalRandomUUID()}} instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11189) Modules query and query-core have overlapping logging id ranges

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11189?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11189: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Modules query and query-core have overlapping logging id ranges > --------------------------------------------------------------- > > Key: ISPN-11189 > URL: https://issues.redhat.com/browse/ISPN-11189 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.1.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 11.0.2.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11024) Unable to use binary memory eviction with protobuf

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11024?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11024: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Unable to use binary memory eviction with protobuf > -------------------------------------------------- > > Key: ISPN-11024 > URL: https://issues.redhat.com/browse/ISPN-11024 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.0.1.Final > Reporter: Jens Reimann > Assignee: Will Burns > Priority: Critical > Fix For: 11.0.2.Final > > > Enabling binary eviction, e.g.: > {code:xml} > <memory> > <binary strategy="REMOVE" size="134217728" eviction="MEMORY"/> > </memory> > {code} > When storing protobuf based types, throws the following exception: > {code} > 15:36:29,859 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (async-thread--p2-t18) ISPN000136: Error executing command PrepareCommand on Cache 'devices', writing keys []: java.lang.IllegalArgumentException: Size of Class class org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper cannot be determined using given entry size calculator :class org.infinispan.container.entries.PrimitiveEntrySizeCalculator > {code} > As protobuf produces a binary representation of the data, it is possible to calculate a size for that object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12045) Clarify jboss-marshalling deprecation message

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12045?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12045: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Clarify jboss-marshalling deprecation message > --------------------------------------------- > > Key: ISPN-12045 > URL: https://issues.redhat.com/browse/ISPN-12045 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 11.0.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.1.Final > > > Currently the server always warns that jboss has been deprecated as it's necessary for the module to be on the classpath of the server in order to provide transcoding of `x-jboss-marshalling` MediaType. > {code:java} > WARN (main) [org.infinispan.PERSISTENCE] ISPN000554: infinispan-boss-marshalling dependency detected, jboss-marshalling has been deprecated and will be removed in the future > {code} > We should update the wording so that it simply states "jboss-marshalling is deprecated and will be removed in the future" -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11024) Unable to use binary memory eviction with protobuf

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11024?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11024: ----------------------------------- Status: Open (was: Pull Request Sent) > Unable to use binary memory eviction with protobuf > -------------------------------------------------- > > Key: ISPN-11024 > URL: https://issues.redhat.com/browse/ISPN-11024 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.0.1.Final > Reporter: Jens Reimann > Assignee: Will Burns > Priority: Critical > Fix For: 11.0.1.Final > > > Enabling binary eviction, e.g.: > {code:xml} > <memory> > <binary strategy="REMOVE" size="134217728" eviction="MEMORY"/> > </memory> > {code} > When storing protobuf based types, throws the following exception: > {code} > 15:36:29,859 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (async-thread--p2-t18) ISPN000136: Error executing command PrepareCommand on Cache 'devices', writing keys []: java.lang.IllegalArgumentException: Size of Class class org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper cannot be determined using given entry size calculator :class org.infinispan.container.entries.PrimitiveEntrySizeCalculator > {code} > As protobuf produces a binary representation of the data, it is possible to calculate a size for that object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12029: ----------------------------------- Fix Version/s: 11.0.2.Final (was: 11.0.1.Final) > Replace Blocking Executor with an EnhancedQueueExecutor > ------------------------------------------------------- > > Key: ISPN-12029 > URL: https://issues.redhat.com/browse/ISPN-12029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final, 11.0.2.Final > > > The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread. > > The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2020