April 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9081) Expose Query.getQueryString() as official API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9081?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9081: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.3.0.Alpha1 Resolution: Done > Expose Query.getQueryString() as official API > --------------------------------------------- > > Key: ISPN-9081 > URL: https://issues.jboss.org/browse/ISPN-9081 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Alpha1 > > > We no longer need to cast to BaseQuery in order to access it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9081) Expose Query.getQueryString() as official API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9081?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9081: ---------------------------------- Sprint: Sprint 9.3.0.Alpha1 > Expose Query.getQueryString() as official API > --------------------------------------------- > > Key: ISPN-9081 > URL: https://issues.jboss.org/browse/ISPN-9081 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Alpha1 > > > We no longer need to cast to BaseQuery in order to access it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9081) Expose Query.getQueryString() as official API

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9081?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9081: -------------------------------- Security: (was: Red Hat Internal) > Expose Query.getQueryString() as official API > --------------------------------------------- > > Key: ISPN-9081 > URL: https://issues.jboss.org/browse/ISPN-9081 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > We no longer need to cast to BaseQuery in order to access it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9085) Add forEach taking IntConsumer to IntSet

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9085?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9085: -------------------------------- Status: Open (was: New) > Add forEach taking IntConsumer to IntSet > ---------------------------------------- > > Key: ISPN-9085 > URL: https://issues.jboss.org/browse/ISPN-9085 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Alpha1 > > > The IntSet class is still missing some methods that have primitive int variants, such as intSpliterator, forEach(IntConsumer), removeIf(IntPredicate). These should be simple to add and actually forEach can be used in a few places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9085) Add forEach taking IntConsumer to IntSet

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9085?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9085: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5925 > Add forEach taking IntConsumer to IntSet > ---------------------------------------- > > Key: ISPN-9085 > URL: https://issues.jboss.org/browse/ISPN-9085 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Alpha1 > > > The IntSet class is still missing some methods that have primitive int variants, such as intSpliterator, forEach(IntConsumer), removeIf(IntPredicate). These should be simple to add and actually forEach can be used in a few places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9085) Add forEach taking IntConsumer to IntSet

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9085?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9085: -------------------------------- Fix Version/s: 9.3.0.Alpha1 > Add forEach taking IntConsumer to IntSet > ---------------------------------------- > > Key: ISPN-9085 > URL: https://issues.jboss.org/browse/ISPN-9085 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Alpha1 > > > The IntSet class is still missing some methods that have primitive int variants, such as intSpliterator, forEach(IntConsumer), removeIf(IntPredicate). These should be simple to add and actually forEach can be used in a few places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9085) Add forEach taking IntConsumer to IntSet

by William Burns (JIRA)

William Burns created ISPN-9085: ----------------------------------- Summary: Add forEach taking IntConsumer to IntSet Key: ISPN-9085 URL: https://issues.jboss.org/browse/ISPN-9085 Project: Infinispan Issue Type: Task Components: Core Reporter: William Burns Assignee: William Burns The IntSet class is still missing some methods that have primitive int variants, such as intSpliterator, forEach(IntConsumer), removeIf(IntPredicate). These should be simple to add and actually forEach can be used in a few places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9084) Conflict resolution should be distributed amongst primary replicas

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-9084: ---------------------------------- Summary: Conflict resolution should be distributed amongst primary replicas Key: ISPN-9084 URL: https://issues.jboss.org/browse/ISPN-9084 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 9.2.1.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Currently conflict resolution is executed entirely on the cluster coordinator on a per segment basis. However, as conflict resolution requires the retrieval of all copies of a given segment to be returned, it's only possible to process entries one segment at a time in an attempt to avoid the coordinator running out of memory. Distributing CR to each segment's primary owner will allow for greater parallelism and scalability as the size of the cluster increases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6009) Stop using thread-locals for marshalling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6009?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-6009: ---------------------------------- Assignee: (was: Dan Berindei) > Stop using thread-locals for marshalling > ---------------------------------------- > > Key: ISPN-6009 > URL: https://issues.jboss.org/browse/ISPN-6009 > Project: Infinispan > Issue Type: Task > Components: Core, Marshalling > Affects Versions: 8.0.2.Final > Reporter: Dan Berindei > Fix For: 9.0.0.Final > > > Marshalling currently uses a thread-local cache for {{RiverMarshaller}} instances. One of the reasons to cache these {{RiverMarshaller}}s was that they always allocate 2 {{IdentityIntMap}}s, one for the instance cache and one for the class cache. > But that also creates a problem, because these caches never shrink. If a {{StateResponseCommand}} includes a lot of {{Serializable}} objects, the caches will grow, and then they will never be used untile the next state transfer. > We should change our internal marshalling API so that it's easy to reuse marshallers without using thread-locals, and to use one-off marshallers for state transfer. > Currently unmarshalling also requires a thread-local to use the proper classloader. A session-based marshalling API would remove the need for the thread-local (especially important with sequential interceptors). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6009) Stop using thread-locals for marshalling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6009?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6009. -------------------------------- Fix Version/s: 9.0.0.Final Resolution: Done Fixed with ISPN-6906 > Stop using thread-locals for marshalling > ---------------------------------------- > > Key: ISPN-6009 > URL: https://issues.jboss.org/browse/ISPN-6009 > Project: Infinispan > Issue Type: Task > Components: Core, Marshalling > Affects Versions: 8.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final > > > Marshalling currently uses a thread-local cache for {{RiverMarshaller}} instances. One of the reasons to cache these {{RiverMarshaller}}s was that they always allocate 2 {{IdentityIntMap}}s, one for the instance cache and one for the class cache. > But that also creates a problem, because these caches never shrink. If a {{StateResponseCommand}} includes a lot of {{Serializable}} objects, the caches will grow, and then they will never be used untile the next state transfer. > We should change our internal marshalling API so that it's easy to reuse marshallers without using thread-locals, and to use one-off marshallers for state transfer. > Currently unmarshalling also requires a thread-local to use the proper classloader. A session-based marshalling API would remove the need for the thread-local (especially important with sequential interceptors). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2018