December 2020 - infinispan-issues

[Red Hat JIRA] (ISPN-11614) PersistenceMarshaller should utilise an independent SerializationContext for user types

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11614?page=com.atlassian.jira.plugi... ] Tristan Tarrant closed ISPN-11614. ---------------------------------- > PersistenceMarshaller should utilise an independent SerializationContext for user types > --------------------------------------------------------------------------------------- > > Key: ISPN-11614 > URL: https://issues.redhat.com/browse/ISPN-11614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.CR1 > > > If a user configures a SerializationContextInitializer it is currently registered to the same SerializationContext as the persistent internal types. This means that it is possible for a user to reference internal protobuf message types in their .proto files. > We should introduce the following: > # A "user" SerializationContext that is used exclusively for user types configured via xml/service-loader/programmatically: > User types are only registered with this context. The global and persistence contexts do not register these types. If a type does not exist in the global/persistence context, then it's wrapped with a MarshallableUserObject and marshalling is delegated to the user marshaller. Previously this only occurred if a custom marshaller was defined as user types were added to the global/persistence context, but as this is no longer the case all user types are wrapped. > # A USER_MARSHALLER created by MarshallerFactory, which if a custom marshaller is not defined creates a ProtoStream based marshaller that consumes the user SerializationContext, if a custom marshaller is defined then that is returned: > This logic was previously in the PersistenceMarshallerImpl, but this allows us to inject the marshaller directly into various places in the code. > # DelegatingUserMarshaller. A wrapper class to call the start/stop of the configured user marshaller and log the marshaller being used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9738) Support for entry iteration in the REST server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9738?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9738: ---------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Support for entry iteration in the REST server > ---------------------------------------------- > > Key: ISPN-9738 > URL: https://issues.redhat.com/browse/ISPN-9738 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 9.4.1.Final > Reporter: Gustavo Fernandes > Assignee: Katia Aresti > Priority: Optional > Fix For: 12.0.0.Final > > > Currently the REST server has an operation to get all keys that has limitations since all the keys are retrieved to a single node before serving to the client. > Ideally, it should have an efficient way of retrieving entries making use of iterators. The API should provide a cursor/scroll/handle so that the client can pull the data without causing memory issues. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12489) Non-transactional INVALIDATION_SYNC cache deadlock

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12489?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-12489: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.CR1 Resolution: Done > Non-transactional INVALIDATION_SYNC cache deadlock > -------------------------------------------------- > > Key: ISPN-12489 > URL: https://issues.redhat.com/browse/ISPN-12489 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.8.Final, 11.0.5.Final, 12.0.0.Dev06 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final, 12.0.0.CR1 > > > Non-transactional invalidation caches use the old locking scheme from Infinispan 4.x, which is prone to deadlocks: > # {{put(k, v1)}} is invoked on node A and acquires lock {{k}} > # {{put(k, v2)}} is invoked on node B and acquires lock {{k}} > # {{A}} sends an {{InvalidateCommand(k)}} RPC to {{B}} > # {{B}} sends an {{InvalidateCommand(k)}} RPC to {{A}} > # The {{InvalidateCommand(k)}} from {{A}} and tries to acquire lock {{k}} on {{B}} > # The {{InvalidateCommand(k)}} from {{B}} and tries to acquire lock {{k}} on {{A}} > # Both {{InvalidateCommand(k)}} lock acquisitions eventually time out and release lock {{k}} on their originators. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12351) ImmutableListCopy makes too many copies

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12351?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12351: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > ImmutableListCopy makes too many copies > --------------------------------------- > > Key: ISPN-12351 > URL: https://issues.redhat.com/browse/ISPN-12351 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 12.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 12.0.0.Final > > > An array copy is not needed when creating a new {{ImmutableListCopy}} instance from another {{ImmutableListCopy}}. > The constructor with 2 list parameters can also avoid one array allocation by pre-allocating the array, or by using one list's array when the other list is empty. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12324) WildFly OpenSSL 2.1.0.Final

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12324?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12324: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > WildFly OpenSSL 2.1.0.Final > --------------------------- > > Key: ISPN-12324 > URL: https://issues.redhat.com/browse/ISPN-12324 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build > Affects Versions: 12.0.0.Dev03 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Final > > > This enables TLS 1.3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12379) Named Query parameters don't work with full text queries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12379?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12379: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Named Query parameters don't work with full text queries > -------------------------------------------------------- > > Key: ISPN-12379 > URL: https://issues.redhat.com/browse/ISPN-12379 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Gustavo Fernandes > Assignee: Nistor Adrian > Priority: Major > Fix For: 12.0.0.Final > > > Original query: {{FROM Entity WHERE description : "word word2 word4"}} > Introducing a parameter, e.g., "param" will not cause a replacement > {{FROM Entity WHERE description : ":param"}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

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.0.0.Final (was: 12.0.0.CR1) > 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.0.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 (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12261) Protocol server transport management

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12261?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12261: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Protocol server transport management > ------------------------------------- > > Key: ISPN-12261 > URL: https://issues.redhat.com/browse/ISPN-12261 > Project: Infinispan > Issue Type: Feature Request > Components: CLI, JMX, reporting and management, Server > Affects Versions: 12.0.0.Dev02 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Final > > > the WF-server had the ability to stop/start a transport via the CLI (ISPN-11240). > The new server should have a similar capability. > h4. Protocol management via CLI > {noformat} > $ cli.sh server connector ls > $ cli.sh server connector describe endpoint-default > $ cli.sh server connector stop endpoint-default > $ cli.sh server connector start endpoint-default > {noformat} > Aside from start/stop, we should also leverage netty's ipfilter handler which allows filtering based on subnet so that traffic can be blocked selectively. > h4. IP Filtering > {code:xml} > <endpoints socket-binding="default" security-realm="default"> > <ip-filter> > <reject from="172.16.0.0/16"/> > <accept from="127.0.0.0/8"/> > </ip-filter> > <hotrod-connector/> > <rest-connector/> > </endpoints> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12218: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Indexed caches with non-indexed entities query inconsistency > ------------------------------------------------------------ > > Key: ISPN-12218 > URL: https://issues.redhat.com/browse/ISPN-12218 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 11.0.3.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: SearchNG > Fix For: 12.0.0.Final > > Attachments: IndexedCacheNonIndexedQueryTest.java > > > When a cache is indexed, but the protobuf entitiy is not: > "FROM Entity" returns zero results > "FROM Entity WHERE <predicate>" return results > It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query > On a side note, if I configure a cache as indexed, but do not index any type in the protobuf, it returns {{ISPN014054: Trying to execute query from xyz, but no type is indexed on cache}}. This should be improved to mention the schema needs to be changed -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12151) Add error count metric

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12151?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12151: ----------------------------------- Fix Version/s: (was: 12.0.0.CR1) > Add error count metric > ---------------------- > > Key: ISPN-12151 > URL: https://issues.redhat.com/browse/ISPN-12151 > Project: Infinispan > Issue Type: Feature Request > Components: Analytics > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final > > > {{CacheMgmtInterceptor}} has metrics for the different kind of key operations, but errors are not tracked. We should add a metric to count errors, and perhaps a histogram for the duration of failed invocations as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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 December 2020