[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)
6 years, 7 months
[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)
6 years, 7 months
[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)
6 years, 7 months
[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)
6 years, 7 months
[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)
6 years, 7 months
[JBoss JIRA] (ISPN-8490) Add compare-and-swap operation to StrongCounter
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8490:
---------------------------------
Summary: Add compare-and-swap operation to StrongCounter
Key: ISPN-8490
URL: https://issues.jboss.org/browse/ISPN-8490
Project: Infinispan
Issue Type: Feature Request
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
A compare-and-swap is preferred over the compare-and-set since it can save a RPC to re-fetch the counter's value. This is important for server-mode as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-8489) Add compare-and-swap operation to StrongCounter
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8489:
---------------------------------
Summary: Add compare-and-swap operation to StrongCounter
Key: ISPN-8489
URL: https://issues.jboss.org/browse/ISPN-8489
Project: Infinispan
Issue Type: Feature Request
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
A compare-and-swap is preferred over the compare-and-set since it can save a RPC to re-fetch the counter's value. This is important for server-mode as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months