December 2020 - infinispan-issues

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

5 years, 3 months

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)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12525) The testsuite should test mariadb by default instead of mysql

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12525?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12525: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > The testsuite should test mariadb by default instead of mysql > ------------------------------------------------------------- > > Key: ISPN-12525 > URL: https://issues.redhat.com/browse/ISPN-12525 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Test Suite > Affects Versions: 12.0.0.Dev06 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12446) Including configuration examples in the server distribution

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12446?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12446: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Including configuration examples in the server distribution > ----------------------------------------------------------- > > Key: ISPN-12446 > URL: https://issues.redhat.com/browse/ISPN-12446 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 12.0.0.Dev05 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Final > > > We should ship the server configurations used by our testsuite as examples in the server distribution. > The files should be flattened (i.e. all xincludes resolved), renamed (to remove `Test`) and cleaned up from test-specific items (e.g. jgroups test stacks). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12443) Remove fake multi-cachemanager support from the server

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12443?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12443: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Remove fake multi-cachemanager support from the server > ------------------------------------------------------ > > Key: ISPN-12443 > URL: https://issues.redhat.com/browse/ISPN-12443 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 12.0.0.Dev05 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Final > > > The initial intention was to support multiple cache managers in the server. We believe this effort isn't worthwhile as it complicates things unnecessarily and community interest has been non-existent. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12503) Add Hot Rod URI support to the RemoteCacheStore configuration

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12503?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12503: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Add Hot Rod URI support to the RemoteCacheStore configuration > ------------------------------------------------------------- > > Key: ISPN-12503 > URL: https://issues.redhat.com/browse/ISPN-12503 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 12.0.0.Dev06 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 12.0.0.Final > > > Hot Rod URIs were introduced in ISPN-11820 > RemoteCacheStore should add support for these to ease configuration -- 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 Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12489?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12489: ----------------------------------- Fix Version/s: (was: 12.0.0.CR1) > 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 > > > 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-12548) Replicated cache get ignores value in zero-capacity nodes

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12548?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12548: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Replicated cache get ignores value in zero-capacity nodes > --------------------------------------------------------- > > Key: ISPN-12548 > URL: https://issues.redhat.com/browse/ISPN-12548 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 12.0.0.Dev07 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final > > > In replicated caches that meet several other conditions, {{cache.get(key)}} is optimized to skip the interceptor chain and to read the entry directly from the data container. > This optimization assumes that the local cache has all the values, and the assumption fails when the local node has a zero capacity factor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12531) Support JGroups fix start port and port offset in the server for FD_SOCK

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12531?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12531: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Support JGroups fix start port and port offset in the server for FD_SOCK > ------------------------------------------------------------------------ > > Key: ISPN-12531 > URL: https://issues.redhat.com/browse/ISPN-12531 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 11.0.5.Final, 12.0.0.Dev06 > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 12.0.0.Final > > > As the server parameter '-o' can add a port offset to the jgroups.bind.port the FD_SOCK port is not affected. Also the port is configured as random which is not ideal. > The legacy server used the socket-bindings to use a fixed start port (udp-fd=54200 and tcp-fd=57800) and incremented the port if the port-offset was used. > This should be similar for the new jgroups configuration. > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12592) Improve error message when XML element is removed

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12592?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12592: ----------------------------------- Fix Version/s: 12.0.0.Final (was: 12.0.0.CR1) > Improve error message when XML element is removed > ------------------------------------------------- > > Key: ISPN-12592 > URL: https://issues.redhat.com/browse/ISPN-12592 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 12.0.0.Dev07 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final > > > When an element is removed from the XML configuration schema, configurations using the old XML namespace trigger a warning that the element is deprecated, including the name of the replacement element. > Configurations files with no namespace declarations are assumed to be using the latest schema and don't trigger the warning, instead they trigger a generic `Unexpected element 'X' encountered` exception. > Assuming the latest schema is the right thing to do, but we need to improve the error message for upgraders. -- 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