[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)
6 years, 10 months
[JBoss JIRA] (ISPN-9925) Provide a reactive transactional API
by Katia Aresti (Jira)
Katia Aresti created ISPN-9925:
----------------------------------
Summary: Provide a reactive transactional API
Key: ISPN-9925
URL: https://issues.jboss.org/browse/ISPN-9925
Project: Infinispan
Issue Type: Sub-task
Reporter: Katia Aresti
Using hotrod transactions, provide a reactive transactional API.
An example could be
{code:java}
CompletionStage<TxReactiveCache> begin();
CompletionStage<TxReactiveCache> commit()
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9923) Provide a reactive basic API
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-9923?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-9923:
-------------------------------
Summary: Provide a reactive basic API (was: Reactive basic API)
> Provide a reactive basic API
> ----------------------------
>
> Key: ISPN-9923
> URL: https://issues.jboss.org/browse/ISPN-9923
> Project: Infinispan
> Issue Type: Sub-task
> Components: API
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
>
> Create a first *ReactiveCache* api based in reactive streams standard. The example API below is not complete, is just an example
> {code:java}
> public interface ReactiveCache<K, V> {
> CompletionStage<V> get(K key);
> CompletionStage<Void> put(K key, V value);
> CompletionStage<V> getAndPut(K key, V value);
> CompletionStage<Void> remove(K key);
> CompletionStage<Boolean> remove(K key, V value);
> CompletionStage<V> getAndRemove(K key);
> CompletionStage<Void> putMany(Publisher<Map.Entry<K, V>> pairs);
> Publisher<K> getKeys();
> Publisher<V> getValues();
> CompletionStage<Long> size();
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9845) Stop exposing InternalMetadata via the persistence SPI
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9845?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9845:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Stop exposing InternalMetadata via the persistence SPI
> ------------------------------------------------------
>
> Key: ISPN-9845
> URL: https://issues.jboss.org/browse/ISPN-9845
> Project: Infinispan
> Issue Type: Sub-task
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> We should stop exposing InternalMetadata via the persistence SPI and add created() methods direct to the MarshallableEntry interface introduced in ISPN-9693. This requires MarshallableEntry to change to:
> {code:java}
> interface MarshallableEntry<K, V> {
> ByteBuffer getKeyBytes();
> ByteBuffer getValueBytes();
> K getKey();
> V getValue();
> Metadata metadata();
> ByteBuffer metadataBytes();
> long created();
> long lastUsed();
> boolean isExpired(long now);
> long expiryTime();
> }
> {code}
> With MarshalledEntry then providing the old method for backwards compatiblity:
> {code:java}
> ByteBuffer getMetadataBytes();
> InternalMetadata getMetadata();
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9924) Create
by Katia Aresti (Jira)
Katia Aresti created ISPN-9924:
----------------------------------
Summary: Create
Key: ISPN-9924
URL: https://issues.jboss.org/browse/ISPN-9924
Project: Infinispan
Issue Type: Sub-task
Components: API
Reporter: Katia Aresti
Add a reactive search search API.
The most simple API could just be using Ickle query.
{code:java}
Publisher<V> find(String ickleQuery);
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months