February 2019 - infinispan-issues

[JBoss JIRA] (ISPN-9927) Provide reactive client listeners

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9927?page=com.atlassian.jira.plugin.... ] Katia Aresti reassigned ISPN-9927: ---------------------------------- Assignee: Katia Aresti > Provide reactive client listeners > --------------------------------- > > Key: ISPN-9927 > URL: https://issues.jboss.org/browse/ISPN-9927 > Project: Infinispan > Issue Type: Sub-task > Components: API > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Provide reactive client listeners new API -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9929) Remote configuration API

by Katia Aresti (Jira)

Katia Aresti created ISPN-9929: ---------------------------------- Summary: Remote configuration API Key: ISPN-9929 URL: https://issues.jboss.org/browse/ISPN-9929 Project: Infinispan Issue Type: Sub-task Reporter: Katia Aresti Make the actual configuration of clients work with the reactive cache API -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9928) Provide new client configuration API

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9928?page=com.atlassian.jira.plugin.... ] Katia Aresti deleted ISPN-9928: ------------------------------- > Provide new client configuration API > ------------------------------------- > > Key: ISPN-9928 > URL: https://issues.jboss.org/browse/ISPN-9928 > Project: Infinispan > Issue Type: Feature Request > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > A new API to configure remote clients -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9928) Provide new client configuration API

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9928?page=com.atlassian.jira.plugin.... ] Katia Aresti reassigned ISPN-9928: ---------------------------------- > Provide new client configuration API > ------------------------------------- > > Key: ISPN-9928 > URL: https://issues.jboss.org/browse/ISPN-9928 > Project: Infinispan > Issue Type: Feature Request > Components: API > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > A new API to configure remote clients -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9928) Provide new client configuration API

by Katia Aresti (Jira)

Katia Aresti created ISPN-9928: ---------------------------------- Summary: Provide new client configuration API Key: ISPN-9928 URL: https://issues.jboss.org/browse/ISPN-9928 Project: Infinispan Issue Type: Feature Request Components: API Reporter: Katia Aresti A new API to configure remote clients -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9927) Provide reactive client listeners

by Katia Aresti (Jira)

Katia Aresti created ISPN-9927: ---------------------------------- Summary: Provide reactive client listeners Key: ISPN-9927 URL: https://issues.jboss.org/browse/ISPN-9927 Project: Infinispan Issue Type: Sub-task Components: API Reporter: Katia Aresti Provide reactive client listeners new API -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9926) Don't run tests for disabled features

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-9926: ------------------------------------- Summary: Don't run tests for disabled features Key: ISPN-9926 URL: https://issues.jboss.org/browse/ISPN-9926 Project: Infinispan Issue Type: Enhancement Components: Test Suite - Core Affects Versions: 9.4.6.Final, 10.0.0.Alpha3 Reporter: Tristan Tarrant Assignee: William Burns Fix For: 10.0.0.Beta1, 9.4.7.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9912) jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster.

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9912?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9912: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta1 Resolution: Done > jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster. > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-9912 > URL: https://issues.jboss.org/browse/ISPN-9912 > Project: Infinispan > Issue Type: Enhancement > Components: JCache > Affects Versions: 10.0.0.Alpha3, 9.4.5.Final, 9.4.6.Final > Reporter: Gabor Papai > Priority: Minor > Fix For: 10.0.0.Beta1 > > Attachments: SSCCE.zip, VisualVM-Sampling.png > > > A jcache.get() call with expiry==eternal creates an unnecessary NPE in LimitExpiryPolicy, it's catched in Expiration.getExpiry(), and a NULL is returned. The LimitExpiryPolicy could return this NULL itself, so the NPE would not happen. In my test this NPE costs ca. 10% of a jcache.get() call (plus the garbage collection overhead). Infinispan is used through JCache interface. > Details: > org.infinispan.jcache.embedded.LimitExpiryFactory.LimitExpiryPolicy doesn't check the "duration" against null, so a NPE will be thrown. > EternalExpiryPolicy returns NULL as getExpiryForAccess() and getExpiryForUpdate(). > It leads to NPE in LimitExpiryPolicy.getExpiryForAccess() and LimitExpiryPolicy.getExpiryForUpdate(). This NPE will be in Expiration.getExpiry() catched, and it's handled as it was NULL. > The LimitExpiryPolicy.getExpiryForUpdate()/getExpiryForAccess() could make the "duration==null" check itself, and could return a NULL, so would not happen the "catch(NPE) { return null; }", and so would it be faster. > Attachment: > SCCE.zip: > small maven project with a unittest (it fails without the fix) and a "TestJCacheLimiterExpiryNpeControl" program to measure it with eg. VisualVM's sampling. > VisualVM-Sampling.png: > CPU Sampling with VisualVM. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9912) jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster.

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9912?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9912: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6635 > jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster. > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-9912 > URL: https://issues.jboss.org/browse/ISPN-9912 > Project: Infinispan > Issue Type: Enhancement > Components: JCache > Affects Versions: 10.0.0.Alpha3, 9.4.5.Final, 9.4.6.Final > Reporter: Gabor Papai > Priority: Minor > Attachments: SSCCE.zip, VisualVM-Sampling.png > > > A jcache.get() call with expiry==eternal creates an unnecessary NPE in LimitExpiryPolicy, it's catched in Expiration.getExpiry(), and a NULL is returned. The LimitExpiryPolicy could return this NULL itself, so the NPE would not happen. In my test this NPE costs ca. 10% of a jcache.get() call (plus the garbage collection overhead). Infinispan is used through JCache interface. > Details: > org.infinispan.jcache.embedded.LimitExpiryFactory.LimitExpiryPolicy doesn't check the "duration" against null, so a NPE will be thrown. > EternalExpiryPolicy returns NULL as getExpiryForAccess() and getExpiryForUpdate(). > It leads to NPE in LimitExpiryPolicy.getExpiryForAccess() and LimitExpiryPolicy.getExpiryForUpdate(). This NPE will be in Expiration.getExpiry() catched, and it's handled as it was NULL. > The LimitExpiryPolicy.getExpiryForUpdate()/getExpiryForAccess() could make the "duration==null" check itself, and could return a NULL, so would not happen the "catch(NPE) { return null; }", and so would it be faster. > Attachment: > SCCE.zip: > small maven project with a unittest (it fails without the fix) and a "TestJCacheLimiterExpiryNpeControl" program to measure it with eg. VisualVM's sampling. > VisualVM-Sampling.png: > CPU Sampling with VisualVM. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9912) jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster.

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9912?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9912: ------------------------------- Status: Open (was: New) > jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster. > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-9912 > URL: https://issues.jboss.org/browse/ISPN-9912 > Project: Infinispan > Issue Type: Enhancement > Components: JCache > Affects Versions: 10.0.0.Alpha3, 9.4.5.Final, 9.4.6.Final > Reporter: Gabor Papai > Priority: Minor > Attachments: SSCCE.zip, VisualVM-Sampling.png > > > A jcache.get() call with expiry==eternal creates an unnecessary NPE in LimitExpiryPolicy, it's catched in Expiration.getExpiry(), and a NULL is returned. The LimitExpiryPolicy could return this NULL itself, so the NPE would not happen. In my test this NPE costs ca. 10% of a jcache.get() call (plus the garbage collection overhead). Infinispan is used through JCache interface. > Details: > org.infinispan.jcache.embedded.LimitExpiryFactory.LimitExpiryPolicy doesn't check the "duration" against null, so a NPE will be thrown. > EternalExpiryPolicy returns NULL as getExpiryForAccess() and getExpiryForUpdate(). > It leads to NPE in LimitExpiryPolicy.getExpiryForAccess() and LimitExpiryPolicy.getExpiryForUpdate(). This NPE will be in Expiration.getExpiry() catched, and it's handled as it was NULL. > The LimitExpiryPolicy.getExpiryForUpdate()/getExpiryForAccess() could make the "duration==null" check itself, and could return a NULL, so would not happen the "catch(NPE) { return null; }", and so would it be faster. > Attachment: > SCCE.zip: > small maven project with a unittest (it fails without the fix) and a "TestJCacheLimiterExpiryNpeControl" program to measure it with eg. VisualVM's sampling. > VisualVM-Sampling.png: > CPU Sampling with VisualVM. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2019