February 2021 - infinispan-issues

[Red Hat JIRA] (ISPN-12736) Docs: Removing productized attributes and conditionals

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12736?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-12736: ------------------------------- Summary: Docs: Removing productized attributes and conditionals (was: Docs: Removing downstream attributes and conditionals) > Docs: Removing productized attributes and conditionals > ------------------------------------------------------ > > Key: ISPN-12736 > URL: https://issues.redhat.com/browse/ISPN-12736 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Remove product-attributes.adoc and clean up conditional statements -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12736) Docs: Removing downstream attributes and conditionals

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12736?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-12736: ------------------------------- Status: Open (was: New) > Docs: Removing downstream attributes and conditionals > ----------------------------------------------------- > > Key: ISPN-12736 > URL: https://issues.redhat.com/browse/ISPN-12736 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Remove product-attributes.adoc and clean up conditional statements -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12736) Docs: Removing downstream attributes and conditionals

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12736?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-12736: ------------------------------- Summary: Docs: Removing downstream attributes and conditionals (was: Docs: Removing downstream attributes and housekeeping) > Docs: Removing downstream attributes and conditionals > ----------------------------------------------------- > > Key: ISPN-12736 > URL: https://issues.redhat.com/browse/ISPN-12736 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Remove product-attributes.adoc and clean up conditional statements -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12735) Simple transaction recovery operation

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12735?page=com.atlassian.jira.plugi... ] Pedro Ruivo commented on ISPN-12735: ------------------------------------ yeah, I thought about that but to be used by the transaction-reaper. Logging a warning if the transaction is in the active state over "completed-tx-timeout" ms. And, if the transaction state is aborted/committed, send another rollback/commit command through the interceptor chain. > Simple transaction recovery operation > ------------------------------------- > > Key: ISPN-12735 > URL: https://issues.redhat.com/browse/ISPN-12735 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > Note: this JIRA doesn't cover the scenario where recovery is enabled (XA transactions) since it has its own recovery operation compliant with JTA. > Note2: hot rod transaction is out of this scope. > Add a management interface (JMX, CLI & REST) to interact with {{GlobalTransaction}} ids, which are unique in the Infinispan instance. The following operation may be useful > * *list*: list all local {{GlobalTransaction}} and its transaction status > * *get*: receives a {{GlobalTransaction}} id and retrieves any information about it: Transaction's xid, Transaction's status, number of locked keys?, nodes involved? > * *forceRollback*: receives a {{GlobalTransaction}}'s id and rollbacks the transaction. If the Transaction status is committed, it does nothing; otherwise, it sends the rollback. If a Transaction does not exist, just broadcast {{TxCompletionNotificationCommand}} to release any "leaked" resources. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12736) Docs: Removing downstream attributes and housekeeping

by Donald Naro (Jira)

Donald Naro created ISPN-12736: ---------------------------------- Summary: Docs: Removing downstream attributes and housekeeping Key: ISPN-12736 URL: https://issues.redhat.com/browse/ISPN-12736 Project: Infinispan Issue Type: Enhancement Components: Documentation Reporter: Donald Naro Assignee: Donald Naro Remove product-attributes.adoc and clean up conditional statements -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12735) Simple transaction recovery operation

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12735?page=com.atlassian.jira.plugi... ] Dan Berindei commented on ISPN-12735: ------------------------------------- It would be great if the transaction table also kept track of when a particular transaction was started. That way the **list** operation could have an optional duration parameter, only listing transactions older than duration seconds. > Simple transaction recovery operation > ------------------------------------- > > Key: ISPN-12735 > URL: https://issues.redhat.com/browse/ISPN-12735 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > Note: this JIRA doesn't cover the scenario where recovery is enabled (XA transactions) since it has its own recovery operation compliant with JTA. > Note2: hot rod transaction is out of this scope. > Add a management interface (JMX, CLI & REST) to interact with {{GlobalTransaction}} ids, which are unique in the Infinispan instance. The following operation may be useful > * *list*: list all local {{GlobalTransaction}} and its transaction status > * *get*: receives a {{GlobalTransaction}} id and retrieves any information about it: Transaction's xid, Transaction's status, number of locked keys?, nodes involved? > * *forceRollback*: receives a {{GlobalTransaction}}'s id and rollbacks the transaction. If the Transaction status is committed, it does nothing; otherwise, it sends the rollback. If a Transaction does not exist, just broadcast {{TxCompletionNotificationCommand}} to release any "leaked" resources. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12735) Simple transaction recovery operation

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12735?page=com.atlassian.jira.plugi... ] Dan Berindei edited comment on ISPN-12735 at 2/16/21 7:13 AM: -------------------------------------------------------------- It would be great if the transaction table also kept track of when a particular transaction was started. That way the *list* operation could have an optional duration parameter, only listing transactions older than duration seconds. was (Author: dan.berindei): It would be great if the transaction table also kept track of when a particular transaction was started. That way the **list** operation could have an optional duration parameter, only listing transactions older than duration seconds. > Simple transaction recovery operation > ------------------------------------- > > Key: ISPN-12735 > URL: https://issues.redhat.com/browse/ISPN-12735 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > Note: this JIRA doesn't cover the scenario where recovery is enabled (XA transactions) since it has its own recovery operation compliant with JTA. > Note2: hot rod transaction is out of this scope. > Add a management interface (JMX, CLI & REST) to interact with {{GlobalTransaction}} ids, which are unique in the Infinispan instance. The following operation may be useful > * *list*: list all local {{GlobalTransaction}} and its transaction status > * *get*: receives a {{GlobalTransaction}} id and retrieves any information about it: Transaction's xid, Transaction's status, number of locked keys?, nodes involved? > * *forceRollback*: receives a {{GlobalTransaction}}'s id and rollbacks the transaction. If the Transaction status is committed, it does nothing; otherwise, it sends the rollback. If a Transaction does not exist, just broadcast {{TxCompletionNotificationCommand}} to release any "leaked" resources. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

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

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12419?page=com.atlassian.jira.plugi... ] Gustavo Fernandes reassigned ISPN-12419: ---------------------------------------- Assignee: Nistor Adrian > 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 > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 12.1.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 (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12735) Simple transaction recovery operation

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-12735: ---------------------------------- Summary: Simple transaction recovery operation Key: ISPN-12735 URL: https://issues.redhat.com/browse/ISPN-12735 Project: Infinispan Issue Type: Enhancement Components: Transactions Reporter: Pedro Ruivo Assignee: Pedro Ruivo Note: this JIRA doesn't cover the scenario where recovery is enabled (XA transactions) since it has its own recovery operation compliant with JTA. Note2: hot rod transaction is out of this scope. Add a management interface (JMX, CLI & REST) to interact with {{GlobalTransaction}} ids, which are unique in the Infinispan instance. The following operation may be useful * *list*: list all local {{GlobalTransaction}} and its transaction status * *get*: receives a {{GlobalTransaction}} id and retrieves any information about it: Transaction's xid, Transaction's status, number of locked keys?, nodes involved? * *forceRollback*: receives a {{GlobalTransaction}}'s id and rollbacks the transaction. If the Transaction status is committed, it does nothing; otherwise, it sends the rollback. If a Transaction does not exist, just broadcast {{TxCompletionNotificationCommand}} to release any "leaked" resources. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12734) Log transaction information on lock timeout

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-12734: ---------------------------------- Summary: Log transaction information on lock timeout Key: ISPN-12734 URL: https://issues.redhat.com/browse/ISPN-12734 Project: Infinispan Issue Type: Enhancement Components: Transactions Affects Versions: 12.0.1.Final Reporter: Pedro Ruivo Assignee: Pedro Ruivo When a transaction fails to acquire a lock, send back the lock owner's {{GlobalTransaction}} with the exception. The idea is to check if the {{GlobalTransaction}} is from a local transaction and check its status, i.e. the {{Transaction.getStatus()}} and {{Transaction.getXid()}}. On other hand, if the {{GlobalTransaction}} is local but the {{Transaction}} does not exist in the {{TransactionTable}}, broadcast a {{TxCompletionNotificationCommand}} to release the lock. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2021