March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10033) Switch from Deployment to StatefulSet

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-10033?page=com.atlassian.jira.plugin... ] Galder Zamarreño reassigned ISPN-10033: --------------------------------------- Assignee: Galder Zamarreño (was: Vittorio Rigamonti) > Switch from Deployment to StatefulSet > ------------------------------------- > > Key: ISPN-10033 > URL: https://issues.jboss.org/browse/ISPN-10033 > Project: Infinispan > Issue Type: Enhancement > Components: Operator > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10002) Make image name configurable via CR Spec

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-10002?page=com.atlassian.jira.plugin... ] Galder Zamarreño updated ISPN-10002: ------------------------------------ Component/s: Operator > Make image name configurable via CR Spec > ---------------------------------------- > > Key: ISPN-10002 > URL: https://issues.jboss.org/browse/ISPN-10002 > Project: Infinispan > Issue Type: Feature Request > Components: Operator > Reporter: Vittorio Rigamonti > Assignee: Vittorio Rigamonti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10032) unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod

by Wolf-Dieter Fink (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Work on ISPN-10032 started by Wolf-Dieter Fink. ----------------------------------------------- > unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10032 > URL: https://issues.jboss.org/browse/ISPN-10032 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Critical > > The documentation of the org.infinispan.client.hotrod.RemoteCache API is confusing. The Class header explain that lifespan expiration will use Seconds or UnitTime depend on the given value but the methods with lifespan will not reflect that with a hint. > API document ([Upstream 9.4| https://docs.jboss.org/infinispan/9.4/apidocs/org/infinispan/client/hotro...] > contains the explanation as followed: > {quote} > *Eviction and expiration:* Unlike local Cache cache, which allows specifying time values with any granularity (as defined by TimeUnit), HotRod only supports seconds as time units. If a different time unit is used instead, HotRod will transparently convert it to seconds, using TimeUnit.toSeconds(long) method. This might result in loss of precision for values specified as nanos or milliseconds. > Another fundamental difference is in the case of lifespan (naturally does NOT apply for max idle): *If number of seconds is bigger than 30 days, this number of seconds is treated as UNIX time and so, represents the number of seconds since 1/1/1970.* > {quote} > But the behavior is different for different ISPN releases. When the specified lifespan value is bigger than 30 days: > - ISPN <=6.2: the value >30days is treated as UNIX time expiry > - ISPN >6.2 <=8.3: the specified value (the maximum is Integer.MAX_VALUE) is treated as lifespan for Hot Rod protocol 2.2 or later. > And as UNIX time expiry for Hot Rod protocol 2.1 or before. > - >8.3: the value >30days is treated as UNIX time expiry regardless of Hot Rod protocol version > According to the API for embedded mode and the method parameters the lifespan should be always treated as seconds, never as UNIX time -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10032) unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod

by Wolf-Dieter Fink (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Wolf-Dieter Fink updated ISPN-10032: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6751 > unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10032 > URL: https://issues.jboss.org/browse/ISPN-10032 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Critical > > The documentation of the org.infinispan.client.hotrod.RemoteCache API is confusing. The Class header explain that lifespan expiration will use Seconds or UnitTime depend on the given value but the methods with lifespan will not reflect that with a hint. > API document ([Upstream 9.4| https://docs.jboss.org/infinispan/9.4/apidocs/org/infinispan/client/hotro...] > contains the explanation as followed: > {quote} > *Eviction and expiration:* Unlike local Cache cache, which allows specifying time values with any granularity (as defined by TimeUnit), HotRod only supports seconds as time units. If a different time unit is used instead, HotRod will transparently convert it to seconds, using TimeUnit.toSeconds(long) method. This might result in loss of precision for values specified as nanos or milliseconds. > Another fundamental difference is in the case of lifespan (naturally does NOT apply for max idle): *If number of seconds is bigger than 30 days, this number of seconds is treated as UNIX time and so, represents the number of seconds since 1/1/1970.* > {quote} > But the behavior is different for different ISPN releases. When the specified lifespan value is bigger than 30 days: > - ISPN <=6.2: the value >30days is treated as UNIX time expiry > - ISPN >6.2 <=8.3: the specified value (the maximum is Integer.MAX_VALUE) is treated as lifespan for Hot Rod protocol 2.2 or later. > And as UNIX time expiry for Hot Rod protocol 2.1 or before. > - >8.3: the value >30days is treated as UNIX time expiry regardless of Hot Rod protocol version > According to the API for embedded mode and the method parameters the lifespan should be always treated as seconds, never as UNIX time -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10032) unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod

by Wolf-Dieter Fink (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Wolf-Dieter Fink updated ISPN-10032: ------------------------------------ Security: (was: Red Hat Internal) > unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10032 > URL: https://issues.jboss.org/browse/ISPN-10032 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > > The documentation of the org.infinispan.client.hotrod.RemoteCache API is confusing. The Class header explain that lifespan expiration will use Seconds or UnitTime depend on the given value but the methods with lifespan will not reflect that with a hint. > API document ([Upstream 9.4| https://docs.jboss.org/infinispan/9.4/apidocs/org/infinispan/client/hotro...] > contains the explanation as followed: > {quote} > *Eviction and expiration:* Unlike local Cache cache, which allows specifying time values with any granularity (as defined by TimeUnit), HotRod only supports seconds as time units. If a different time unit is used instead, HotRod will transparently convert it to seconds, using TimeUnit.toSeconds(long) method. This might result in loss of precision for values specified as nanos or milliseconds. > Another fundamental difference is in the case of lifespan (naturally does NOT apply for max idle): *If number of seconds is bigger than 30 days, this number of seconds is treated as UNIX time and so, represents the number of seconds since 1/1/1970.* > {quote} > But the behavior is different for different ISPN releases. When the specified lifespan value is bigger than 30 days: > - ISPN <=6.2: the value >30days is treated as UNIX time expiry > - ISPN >6.2 <=8.3: the specified value (the maximum is Integer.MAX_VALUE) is treated as lifespan for Hot Rod protocol 2.2 or later. > And as UNIX time expiry for Hot Rod protocol 2.1 or before. > - >8.3: the value >30days is treated as UNIX time expiry regardless of Hot Rod protocol version > According to the API for embedded mode and the method parameters the lifespan should be always treated as seconds, never as UNIX time -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10031) Remove doc regarding expiration not working with state transfer

by William Burns (Jira)

William Burns created ISPN-10031: ------------------------------------ Summary: Remove doc regarding expiration not working with state transfer Key: ISPN-10031 URL: https://issues.jboss.org/browse/ISPN-10031 Project: Infinispan Issue Type: Task Components: Documentation-Core Reporter: William Burns Assignee: William Burns Fix For: 10.0.0.Beta3 ISPN-4075 changed it so now expiration times are updated properly when retrieving entries via state transfer. We need to make sure documentation doesn't erroneously talk about this limitation anymore. One example is http://infinispan.org/docs/dev/user_guide/user_guide.html#expiration_maxi... with the third bullet point. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10029) Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/ISPN-10029?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on ISPN-10029: ------------------------------------- Fix will need to be backported to 9.3.x and 9.4.x. > Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK > --------------------------------------------------------------------------------------------------- > > Key: ISPN-10029 > URL: https://issues.jboss.org/browse/ISPN-10029 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.8.Final > Reporter: Paul Ferraro > Priority: Major > Attachments: InvalidationLockingTest.java > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10025) Add filters to counters events

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10025?page=com.atlassian.jira.plugin... ] Ryan Emerson commented on ISPN-10025: ------------------------------------- A potentially useful filter would be for an event to be fired once a counter hits a given value. For example, if maintaining a decrementing health count, you want to receive an event at a certain threshold before the lower_bound is reached in order to take some action before health = lower_bound. > Add filters to counters events > ------------------------------ > > Key: ISPN-10025 > URL: https://issues.jboss.org/browse/ISPN-10025 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > For strong counters, it makes sense to filter what kind of event do you want. For example, the user may need only the bounds events (i.e. the counter reached the lower or upper bound). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10005) Use DNS ping for cluster formation

by Vittorio Rigamonti (Jira)

[ https://issues.jboss.org/browse/ISPN-10005?page=com.atlassian.jira.plugin... ] Vittorio Rigamonti updated ISPN-10005: -------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan-operator/pull/28, https://github.com/infinispan/infinispan/pull/6749, https://github.com/infinispan/infinispan/pull/6750 (was: https://github.com/infinispan/infinispan-operator/pull/28) > Use DNS ping for cluster formation > ---------------------------------- > > Key: ISPN-10005 > URL: https://issues.jboss.org/browse/ISPN-10005 > Project: Infinispan > Issue Type: Feature Request > Components: Operator > Reporter: Vittorio Rigamonti > Assignee: Vittorio Rigamonti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10030) Add Automatic-Module-Names to jars

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-10030: -------------------------------------- Summary: Add Automatic-Module-Names to jars Key: ISPN-10030 URL: https://issues.jboss.org/browse/ISPN-10030 Project: Infinispan Issue Type: Feature Request Components: Build Reporter: Tristan Tarrant Assignee: Tristan Tarrant All jars should have a Automatic-Module-Name entry added to the MANIFEST -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019