January 2021 - infinispan-issues - Jboss List Archives

[Red Hat JIRA] (ISPN-11784) Combine netty and non blocking thread pools

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11784?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11784: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Combine netty and non blocking thread pools > ------------------------------------------- > > Key: ISPN-11784 > URL: https://issues.redhat.com/browse/ISPN-11784 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.1.0.Final > > > We cannot simply drop in our non blocking thread pool as an executor for netty io event loop group. The reason is because Netty takes over control of that thread and only runs tasks submitted to its various event loops. To consolidate these we need to replace our non blocking thread pool with the netty thread pool so it can awake the thread to process tasks. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11682) Remove RemoteCacheManager.createNearCacheService

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11682?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11682: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Remove RemoteCacheManager.createNearCacheService > ------------------------------------------------ > > Key: ISPN-11682 > URL: https://issues.redhat.com/browse/ISPN-11682 > Project: Infinispan > Issue Type: Sub-task > Components: Hot Rod > Reporter: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11683) Remove ConfigurationBuilder.balancingStrategy(FailoverRequestBalancingStrategy)

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11683?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11683: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Remove ConfigurationBuilder.balancingStrategy(FailoverRequestBalancingStrategy) > ------------------------------------------------------------------------------- > > Key: ISPN-11683 > URL: https://issues.redhat.com/browse/ISPN-11683 > Project: Infinispan > Issue Type: Sub-task > Components: Hot Rod > Reporter: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11832) ProtobufMetadataManagerInterceptor is blocking

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11832?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11832: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > ProtobufMetadataManagerInterceptor is blocking > ---------------------------------------------- > > Key: ISPN-11832 > URL: https://issues.redhat.com/browse/ISPN-11832 > Project: Infinispan > Issue Type: Bug > Components: Indexing > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.1.0.Final > > > The interceptor uses invoke on the AsyncInterceptorChain in multiple places. This invocation can and will block. We should be using invokeAsync and chaining the stage. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11822) Quartz JobStore

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11822?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11822: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Quartz JobStore > --------------- > > Key: ISPN-11822 > URL: https://issues.redhat.com/browse/ISPN-11822 > Project: Infinispan > Issue Type: Feature Request > Components: Integration > Reporter: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > A JobStore for Quartz for both embedded and remote. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11838) Native CLI compiled with GraalVM

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11838?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11838: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Native CLI compiled with GraalVM > -------------------------------- > > Key: ISPN-11838 > URL: https://issues.redhat.com/browse/ISPN-11838 > Project: Infinispan > Issue Type: Feature Request > Components: CLI > Affects Versions: 11.0.0.Dev05 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.1.0.Final > > > We should be able to build a native CLI using GraalVM's `native-image` -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11968) Deprecate application/octet-stream encoding parameter in REST API

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11968?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11968: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Deprecate application/octet-stream encoding parameter in REST API > ----------------------------------------------------------------- > > Key: ISPN-11968 > URL: https://issues.redhat.com/browse/ISPN-11968 > Project: Infinispan > Issue Type: Task > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > The REST API allows a client to encode {{application/octet-stream}} keys and values either in BASE64 or in an ad-hoc {{hex}} format, depending on the value of the {{encoding}} parameter. > REST, being based on HTTP, offers a more natural encoding of {{application/octet-stream}}: > * In the URI, the keys should be [percent-encoded|https://en.wikipedia.org/wiki/Percent-encoding] > * Even when listing the keys in the cache, and the keys appear in the body, it might be a good idea to list the keys as relative URIs (therefore percent-encoded) > * The values only appear in the request/response body, so they should not be encoded at all -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12052) Allow CLI batch files to be processed on server startup

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12052?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12052: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Allow CLI batch files to be processed on server startup > ------------------------------------------------------- > > Key: ISPN-12052 > URL: https://issues.redhat.com/browse/ISPN-12052 > Project: Infinispan > Issue Type: Enhancement > Components: CLI, Server > Affects Versions: 11.0.0.Final > Reporter: Ryan Emerson > Priority: Major > Fix For: 12.1.0.Final > > > The recommended way to configure Infinispan is now via the CLI. However, currently the server is unaware of the CLI syntax and simply processes it's command via the REST endpoint. We should enhance the server so that it's aware of the CLI syntax and is able to process one or more CLI batch files upon server startup. Crucially, the server's health checks should not pass untill all batches have been processed so that all configured resources are available before the server signals that it's ready. > Providing batch files on startup is very useful for the Infinispan image, as it allows users to provide static configuration of caches at boot time without having to configure .xml. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12025) JGroupsTransport should handle response unmarshalling errors as remote errors

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12025?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12025: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > JGroupsTransport should handle response unmarshalling errors as remote errors > ----------------------------------------------------------------------------- > > Key: ISPN-12025 > URL: https://issues.redhat.com/browse/ISPN-12025 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > {{JGroupsTransport.processResponse}} doesn't process a response from a remote node if there is an unmarshalling problem, it just logs an error message and lets the request eventually time out. It should instead call the {{ResponseCollector}} with an {{ExceptionResponse}}, so the request can finish immediately (albeit with an error). -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12172) Make the number of segments dynamic

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12172?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12172: ----------------------------------- Fix Version/s: 12.1.0.Final (was: 12.0.0.Final) > Make the number of segments dynamic > ----------------------------------- > > Key: ISPN-12172 > URL: https://issues.redhat.com/browse/ISPN-12172 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.1.0.Final > > > Now that the data container and stores store segment information, it's becoming harder and harder to change the number of segments to accommodate a growth in the number of nodes and preserve all the data. > We should investigate removing the {{numSegments}} configuration attribute and using an {{effectiveNumSegments}} that is the first power of 2 that's bigger than 10 * <cluster size> (customizable, maybe?) and at least as big as the previous {{effectiveNumSegments}}. > The number of segments increase would be decided by the coordinator on join and would require state transfer, as {{SyncConsistentHashFactory}} would not assign the split segments to exactly the same owners (although it would have to be pretty close in order to make this practical). > We would like to avoid updating the segment of every persisted entry on {{effectiveNumSegments}} changes, so the segment stored in persisted entries should be computed based on the maximum value we will allow for {{effectiveNumSegments}}, e.g. 2^16. We would then use a shift+mask to obtain the "effective segment" of the key, and range queries when obtaining all the keys in a segment. > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021