October 2020 - infinispan-issues - Jboss List Archives

[Red Hat JIRA] (ISPN-12408) Remove support for the default null token on index fields

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-12408?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-12408: --------------------------------- Status: Open (was: New) > Remove support for the default null token on index fields > --------------------------------------------------------- > > Key: ISPN-12408 > URL: https://issues.redhat.com/browse/ISPN-12408 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Reporter: Yoann Rodière > Assignee: Yoann Rodière > Priority: Major > Fix For: 12.0.0.Dev05 > > > The default null token isn't supported anymore in Hibernate Search 6. Each field that takes advantage of the {{indexNullAs}} feature should define the null token explicitly. > The {{indexNullAs}} feature was deprecated in Infinispan 11: https://infinispan.org/docs/11.0.x/titles/upgrading/upgrading.html#entity... > Also, Hibernate Search 6 offers an {{exist}} predicate, which is used in Ickle for {{IS NOT NULL}} conditions; so {{indexNullAs}} is no longer as important as before. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (IPROTO-167) Allow setter methods to be annotated with @ProtoField even when @ProtoFactory is used

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-167?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-167: --------------------------------- Sprint: DataGrid Sprint #50 > Allow setter methods to be annotated with @ProtoField even when @ProtoFactory is used > ------------------------------------------------------------------------------------- > > Key: IPROTO-167 > URL: https://issues.redhat.com/browse/IPROTO-167 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.0.Final > Reporter: Nistor Adrian > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

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

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-12419?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-12419: --------------------------------- Sprint: DataGrid Sprint #50 > 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.Dev05 > > > 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)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12423) Infispan thread freezing (STUCK)

by Evgenii Balakhonov (Jira)

[ https://issues.redhat.com/browse/ISPN-12423?page=com.atlassian.jira.plugi... ] Evgenii Balakhonov updated ISPN-12423: -------------------------------------- Description: During huge load some threads hangs on java.lang.Thread.State: WAITING (parking) java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) I attached Infinispan configuration and two thread dump: * off heap storage enabled * heap storage enabled was: During huge load some threads hangs on java.lang.Thread.State: WAITING (parking) java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) I attached Infinispan configuration and thread dump > Infispan thread freezing (STUCK) > -------------------------------- > > Key: ISPN-12423 > URL: https://issues.redhat.com/browse/ISPN-12423 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.4.Final > Reporter: Evgenii Balakhonov > Priority: Major > Attachments: Thread dump - heap storage.txt, Thread dump.txt, cache-configuration-jdbc.xml > > > During huge load some threads hangs on > java.lang.Thread.State: WAITING (parking) > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) > at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) > at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) > I attached Infinispan configuration and two thread dump: > * off heap storage enabled > * heap storage enabled -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12423) Infispan thread freezing (STUCK)

by Evgenii Balakhonov (Jira)

[ https://issues.redhat.com/browse/ISPN-12423?page=com.atlassian.jira.plugi... ] Evgenii Balakhonov updated ISPN-12423: -------------------------------------- Attachment: Thread dump - heap storage.txt > Infispan thread freezing (STUCK) > -------------------------------- > > Key: ISPN-12423 > URL: https://issues.redhat.com/browse/ISPN-12423 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.4.Final > Reporter: Evgenii Balakhonov > Priority: Major > Attachments: Thread dump - heap storage.txt, Thread dump.txt, cache-configuration-jdbc.xml > > > During huge load some threads hangs on > java.lang.Thread.State: WAITING (parking) > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) > at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) > at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) > I attached Infinispan configuration and thread dump -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11189) Modules query and query-core have overlapping logging id ranges

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-11189?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-11189: --------------------------------- Sprint: DataGrid Sprint #39, DataGrid Sprint #50 (was: DataGrid Sprint #39) > Modules query and query-core have overlapping logging id ranges > --------------------------------------------------------------- > > Key: ISPN-11189 > URL: https://issues.redhat.com/browse/ISPN-11189 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.1.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 11.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12404) Provide Ickle variant for contains/containsAll/containsAny from the query builder dsl

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-12404?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-12404: --------------------------------- Labels: SearchNG (was: ) > Provide Ickle variant for contains/containsAll/containsAny from the query builder dsl > ------------------------------------------------------------------------------------- > > Key: ISPN-12404 > URL: https://issues.redhat.com/browse/ISPN-12404 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Labels: SearchNG > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-9492) Unknown type: 130

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-9492?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on ISPN-9492: ------------------------------------- [~schernolyas], [~gustavonalle], the issue that is linked as being the cause of this is resolved. Can we close this now ? I'm leaning towards `yes` :) > Unknown type: 130 > ----------------- > > Key: ISPN-9492 > URL: https://issues.redhat.com/browse/ISPN-9492 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.3.1.Final > Reporter: Sergey Chernolyas > Priority: Blocker > > I take exception: > _____________ > Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=22 returned server error (status=0x85): java.io.IOException: Unknown type: 130 > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:333) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:179) > at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:138) > at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:98) > at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) > at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1414) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) > at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:945) > at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:806) > at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404) > at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304) > at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > ____________ > Main problem of the exception is cache became to unmanagable. I can't clear cache! > After get the exception I need to stop cluster and remove files of external storage. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (IPROTO-167) Allow setter methods to be annotated with @ProtoField even when @ProtoFactory is used

by Nistor Adrian (Jira)

Nistor Adrian created IPROTO-167: ------------------------------------ Summary: Allow setter methods to be annotated with @ProtoField even when @ProtoFactory is used Key: IPROTO-167 URL: https://issues.redhat.com/browse/IPROTO-167 Project: Infinispan ProtoStream Issue Type: Bug Affects Versions: 4.3.0.Final Reporter: Nistor Adrian -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12418) Docs: Clustered Locks

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12418?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-12418: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8772, https://github.com/infinispan/infinispan/pull/8771 > Docs: Clustered Locks > --------------------- > > Key: ISPN-12418 > URL: https://issues.redhat.com/browse/ISPN-12418 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 11.0.4.Final, 12.0.0.Dev04 > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Need to update Clustered Locks docu. Currently exposes details for functionality that is not implemented and is labelled as experimental. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2020