November 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8456) Regression in rest reads performance

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8456?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes edited comment on ISPN-8456 at 11/6/17 4:47 AM: ------------------------------------------------------------------ ISPN-8467 has been merged, I believe the regression should be solved, let's wait for the Radar Gun test was (Author: gustavonalle): ISPN-8467 has been merged, I believe the regression should be solve, let's wait for the Radar Gun test > Regression in rest reads performance > ------------------------------------ > > Key: ISPN-8456 > URL: https://issues.jboss.org/browse/ISPN-8456 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8481) Lazily calculate hashCode for WrappedByteArray

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8481?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8481: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Lazily calculate hashCode for WrappedByteArray > ---------------------------------------------- > > Key: ISPN-8481 > URL: https://issues.jboss.org/browse/ISPN-8481 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > We don't always use the hashCode for a WrappedByteArray. By always calculating it this adds additional cost, we should see if we can change this safely. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8493) Querying via Rest endpoint

by Pedro Zapata (JIRA)

Pedro Zapata created ISPN-8493: ---------------------------------- Summary: Querying via Rest endpoint Key: ISPN-8493 URL: https://issues.jboss.org/browse/ISPN-8493 Project: Infinispan Issue Type: Feature Request Components: Server Affects Versions: 9.1.0.Final Reporter: Pedro Zapata Assignee: Gustavo Fernandes Fix For: 9.2.0.Beta1, 9.2.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8492) Implement a caching filter for Envoy

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-8492: ------------------------------------- Summary: Implement a caching filter for Envoy Key: ISPN-8492 URL: https://issues.jboss.org/browse/ISPN-8492 Project: Infinispan Issue Type: Task Reporter: Tristan Tarrant Envoy is the proxy used by Istio. It is possible to implement filters that intercept and manipulate requests/response. We should investigate the implementation of a filter based on Infinispan leveraging the C++ client. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8467) Memory Leak in the Rest server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8467?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8467: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Memory Leak in the Rest server > ------------------------------ > > Key: ISPN-8467 > URL: https://issues.jboss.org/browse/ISPN-8467 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.2.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Beta1 > > > The Netty rest server upon each connection will install the {{Http20RequestHandler}} that in turn creates a new instance of {{CacheOperations}} and {{RestCacheManager}} objects. > The {{RestCacheManager}} on every connection, among other things, will create hashmaps to keep cache instances, and will try to register every time a new {{RestSourceMigrator}} which gets accumulated in the {{RollingUpgradeManager}}. > Those objects should be shared across all channels so that they can efficiently cache resources and avoid creating lots of garbage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8467) Memory Leak in the Rest server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8467?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8467: ---------------------------------- Fix Version/s: 9.2.0.Beta1 > Memory Leak in the Rest server > ------------------------------ > > Key: ISPN-8467 > URL: https://issues.jboss.org/browse/ISPN-8467 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.2.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Beta1 > > > The Netty rest server upon each connection will install the {{Http20RequestHandler}} that in turn creates a new instance of {{CacheOperations}} and {{RestCacheManager}} objects. > The {{RestCacheManager}} on every connection, among other things, will create hashmaps to keep cache instances, and will try to register every time a new {{RestSourceMigrator}} which gets accumulated in the {{RollingUpgradeManager}}. > Those objects should be shared across all channels so that they can efficiently cache resources and avoid creating lots of garbage. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8423: -------------------------------- Fix Version/s: 9.2.0.Beta1 9.1.3.Final > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8423: -------------------------------- Status: Open (was: New) > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8423: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5566 > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8491) Add streaming variant of off heap to not create byte[] instances

by William Burns (JIRA)

William Burns created ISPN-8491: ----------------------------------- Summary: Add streaming variant of off heap to not create byte[] instances Key: ISPN-8491 URL: https://issues.jboss.org/browse/ISPN-8491 Project: Infinispan Issue Type: Sub-task Components: Off Heap Reporter: William Burns Fix For: 9.2.0.Final Currently off heap has to create a byte[] to copy memory from off heap. This is a waste of CPU and memory to do so. Instead we should have a streaming variant Output that the GlobalMarshaller can use that doesn't need all of this unnecessary copying. Unfortunately GlobalMarshaller is currently internally hard coded to require the usage of byte[] so we would have to tweak some code there as well to allow this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 November 2017