November 2019 - infinispan-issues

[JBoss JIRA] (ISPN-10943) Handle thread pool queue rejection when invoking rxjava code

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10943?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10943. --------------------------------- Resolution: Done > Handle thread pool queue rejection when invoking rxjava code > ------------------------------------------------------------ > > Key: ISPN-10943 > URL: https://issues.jboss.org/browse/ISPN-10943 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.1.0.Beta1 > > > Currently the BlockingRejectedExecutionHandler throws a Rejected exception at https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... when a non blocking thread can't pass a task to the blocking queue. > Unfortunately in rxjava 2 they catch the exception and log it and do nothing else at https://github.com/ReactiveX/RxJava/blob/2.x/src/main/java/io/reactivex/i.... This leads to having a publisher that never completes. > We should be able to throw a different exception, not RejectedExecutionException, and rxjava2 should catch and properly set it in the publisher to prevent this from happening. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10784) XSite Docs: Async vs Sync

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10784?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10784: ------------------------------- Sprint: DataGrid Sprint #37 (was: DataGrid Sprint #36) > XSite Docs: Async vs Sync > ------------------------- > > Key: ISPN-10784 > URL: https://issues.jboss.org/browse/ISPN-10784 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Servers > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Expand xsite docs on ASYNC SYNC settings, client, intra-cluster and xsite. > SYNC ensure the call is complete or not > whereas ASYNC might cause inconsistency if there is a failure - and the user get only a log WARN message (or nothing) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10755) Operator Docs: Safe shutdown

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10755?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10755: ------------------------------- Sprint: DataGrid Sprint #37 (was: DataGrid Sprint #36) > Operator Docs: Safe shutdown > ---------------------------- > > Key: ISPN-10755 > URL: https://issues.jboss.org/browse/ISPN-10755 > Project: Infinispan > Issue Type: Task > Components: Documentation-Servers > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ] Diego Lovison reassigned ISPN-10955: ------------------------------------ Assignee: (was: Diego Lovison) > Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-10955 > URL: https://issues.jboss.org/browse/ISPN-10955 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.1.Final > Reporter: Diego Lovison > Priority: Major > > 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types. > The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'. > Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ] Diego Lovison commented on ISPN-10955: -------------------------------------- http://openjdk.java.net/jeps/218 > Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-10955 > URL: https://issues.jboss.org/browse/ISPN-10955 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.1.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types. > The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'. > Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ] Work on ISPN-10955 stopped by Diego Lovison. -------------------------------------------- > Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-10955 > URL: https://issues.jboss.org/browse/ISPN-10955 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.1.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types. > The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'. > Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10192) Non-blocking cross-site requests

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10192?page=com.atlassian.jira.plugin... ] Pedro Ruivo closed ISPN-10192. ------------------------------ > Non-blocking cross-site requests > -------------------------------- > > Key: ISPN-10192 > URL: https://issues.jboss.org/browse/ISPN-10192 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Final > > > Current implementation blocks the command in the interceptor chain waiting for it to be replicated to the remote site. This should be changed to a non-blocking approach. > Returning an {{InvocationStage}} should solve the issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ] Pedro Ruivo closed ISPN-10657. ------------------------------ > Handle async-xsite in parallel > ------------------------------ > > Key: ISPN-10657 > URL: https://issues.jboss.org/browse/ISPN-10657 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Affects Versions: 10.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Final > > > Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed. > This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel. > It should improve the response time, however, there is no free lunch. The following is expected: > * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel > * An increase in memory: it chains the updates (queue) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10957) Index/Query by key

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10957?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10957: --------------------------------- Status: Open (was: New) > Index/Query by key > ------------------ > > Key: ISPN-10957 > URL: https://issues.jboss.org/browse/ISPN-10957 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Tristan Tarrant > Assignee: Nistor Adrian > Priority: Major > > We should offer the ability to query by key both in non-indexed mode as well as adding the key to the index using some special field name -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10883) [REST] Simultaneous call to stop don't stop the servers

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10883?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10883. --------------------------------- Resolution: Done > [REST] Simultaneous call to stop don't stop the servers > ------------------------------------------------------- > > Key: ISPN-10883 > URL: https://issues.jboss.org/browse/ISPN-10883 > Project: Infinispan > Issue Type: Bug > Components: REST, Server > Affects Versions: 10.0.0.Final, 10.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.0.Beta1 > > > This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: > http://localhost:11222/rest/v2/server?action=stop > http://localhost:11322/rest/v2/server?action=stop > http://localhost:11422/rest/v2/server?action=stop > All the commands return code 200 but the servers are not stopped, the processes are still alive. > This is a regression from 10.0.0.CR3 where those ops were working correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2019