December 2020 - infinispan-issues

[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)

4 years

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)

4 years

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)

4 years

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)

4 years

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)

4 years

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)

4 years

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)

4 years

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)

4 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12419) Expose indexed-embedding as a separate annotation in Protobuf index mapping

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12419?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12419: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Expose indexed-embedding as a separate annotation in Protobuf index mapping > --------------------------------------------------------------------------- > > Key: ISPN-12419 > URL: https://issues.redhat.com/browse/ISPN-12419 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Yoann Rodière > Priority: Major > Labels: SearchNG > Fix For: 12.0.0.Final > > > This ticket is about a behavior change between Infinispan 11 and 12 caused by the upgrade to Hibernate Search 6; it must be addressed before the release of Infinispan 12. > In Infinispan 11, when mapping a Protobuf type to an index, one must use the {{@Field}} annotation in order to mark a composite type as "embedded", e.g.: > {code} > message User { > /** > * @Field(store = Store.YES) > * @SortableField > */ > required int32 id = 1; > /** > * @Field(store = Store.YES) > */ > optional User manager = 2; > } > {code} > The {{@Field}} annotation on {{manager}} does not actually create a field: instead, it specifies that all fields defined in {{manager}} should be embedded in {{User}}. In this case, it means user will have a field named {{manager.id}}. > One obvious problem is that we're hijacking an annotation to express something really different from what it was intended for. It would arguably be better to have a dedicated annotation for that kind of embedding, similar to the {{@IndexedEmbedded}} annotation from Hibernate Search. > But a less obvious and much more problematic consequence of that choice is that we are forced to put implicit limits on recursive models, and users cannot control these limits. Indeed, Infinispan 12 only uses static metamodels when defining Hibernate Search indexes, so infinite recursion is simply not an option. In the example above, we have to declare all fields at bootstrap, and that includes the recursions such as {{manager.id}}, {{manager.manager.id}}, {{manager.manager.manager.id}}, etc. Currently we limit embedding depth to {{7}}, which is very arbitrary. > To solve _that_ problem, we have two alternatives: > # Embrace infinite recursion, meaning we will define a dynamic schema. In the example above, we would define static fields {{manager}}, {{manager.id}} and {{manager.manager}}, and inside {{manager}} we would define dynamic fields for path patterns {{\*.manager}} (object field) and {{\*.manager.id}} (Integer field, stored, sortable). The main problem with this behavior is there is a possibility that user schemas introduce conflicts (e.g. two definitions of "manager" in two different embedded types), which will probably lead to runtime errors or non-matching queries. > # Switch to a dedicated annotation to configure embedding, e.g. {{@IndexedEmbedded}}. This annotation could be unlimited by default. Hibernate Search will throw an exception if that leads infinite recursion, and when that happens, users will be able to set attributes on the annotation to control recursion, for example with {{@IndexedEmbedded(includePaths = <finite list of field paths to embed>)}} or {{@IndexedEmbedded(includeDepth = <depth of recursion when indexing>)}}. > I'd be in favor of solution 2, which is the solution we implement in the Hibernate Search / Hibernate ORM mapper : https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#... > Judging from a previous conversation, it seems [~anistor] [agrees|https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/...]. > See also the full conversation, starting here: https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/topic/I... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12430: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final > > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... > > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2020