January 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9913) Upgrade infinispan SB starter to 9.4.6.Final

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9913?page=com.atlassian.jira.plugin.... ] Katia Aresti reassigned ISPN-9913: ---------------------------------- Assignee: Katia Aresti > Upgrade infinispan SB starter to 9.4.6.Final > -------------------------------------------- > > Key: ISPN-9913 > URL: https://issues.jboss.org/browse/ISPN-9913 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Use the last infinispan release in the starter -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9913) Upgrade infinispan SB starter to 9.4.6.Final

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9913?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9913: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-spring-boot/pull/97 > Upgrade infinispan SB starter to 9.4.6.Final > -------------------------------------------- > > Key: ISPN-9913 > URL: https://issues.jboss.org/browse/ISPN-9913 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Reporter: Katia Aresti > Priority: Major > > Use the last infinispan release in the starter -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9913) Upgrade infinispan SB starter to 9.4.6.Final

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9913?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9913: ------------------------------- Status: Open (was: New) > Upgrade infinispan SB starter to 9.4.6.Final > -------------------------------------------- > > Key: ISPN-9913 > URL: https://issues.jboss.org/browse/ISPN-9913 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Reporter: Katia Aresti > Priority: Major > > Use the last infinispan release in the starter -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9913) Upgrade infinispan SB starter to 9.4.6.Final

by Katia Aresti (Jira)

Katia Aresti created ISPN-9913: ---------------------------------- Summary: Upgrade infinispan SB starter to 9.4.6.Final Key: ISPN-9913 URL: https://issues.jboss.org/browse/ISPN-9913 Project: Infinispan Issue Type: Component Upgrade Components: Spring Integration Reporter: Katia Aresti Use the last infinispan release in the starter -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9906) Add clustered lock to wildfly modules

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9906?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9906: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6627, https://github.com/infinispan/infinispan/pull/6634 (was: https://github.com/infinispan/infinispan/pull/6627) > Add clustered lock to wildfly modules > ------------------------------------- > > Key: ISPN-9906 > URL: https://issues.jboss.org/browse/ISPN-9906 > Project: Infinispan > Issue Type: Bug > Components: Clustered Locks > Affects Versions: 9.4.6.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > Fix For: 9.4.7.Final > > > Wildfly modules don't include clustered locks jar to be used in embedded mode. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 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 Gabor Papai (Jira)

Gabor Papai created ISPN-9912: --------------------------------- Summary: 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: 9.4.6.Final, 9.4.5.Final, 10.0.0.Alpha3 Reporter: Gabor Papai 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9903) Docs: Clustered Locks Config Example

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9903?page=com.atlassian.jira.plugin.... ] Don Naro closed ISPN-9903. -------------------------- > Docs: Clustered Locks Config Example > ------------------------------------ > > Key: ISPN-9903 > URL: https://issues.jboss.org/browse/ISPN-9903 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Alpha3, 9.4.6.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9888) Docs: Default JGroups for Infinispan

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9888?page=com.atlassian.jira.plugin.... ] Don Naro closed ISPN-9888. -------------------------- > Docs: Default JGroups for Infinispan > ------------------------------------ > > Key: ISPN-9888 > URL: https://issues.jboss.org/browse/ISPN-9888 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 9.4.5.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 9.4.7.Final > > > Default properties in jgroups-defaults.xml are not the same as JGroups defaults. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ] Don Naro closed ISPN-9880. -------------------------- > Docs: Hot Rod Transaction Support Feedback > ------------------------------------------ > > Key: ISPN-9880 > URL: https://issues.jboss.org/browse/ISPN-9880 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Beta1, 9.4.6.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.7.Final > > > https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht... > Feedback for on Hot Rod Transaction docs: > Server Guide > - 6.2.6 Transactions > Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities. > User Guide > - 20.7.21.2.2 Transaction Modes > "The transaction mode names are the same for server configuration and for client settings. > To prevent from confusion it should be clarified here that this is the client setting > and the server will not work correctly if the client use Tx but the server has no Tx setting. > This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)" > - 20.7.21 > "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic. > But there is no highlighted node that the consistence is possibly affected by that. > There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible." > Additionally: > "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations. > If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found. > So this will be 99% of the use cases (or more)" -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4075: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > State transfer should preserve the creation timestamp of entries > ---------------------------------------------------------------- > > Key: ISPN-4075 > URL: https://issues.jboss.org/browse/ISPN-4075 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 10.0.0.Final, 9.4.7.Final > > > State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. > The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2019