March 2019 - infinispan-issues - Jboss List Archives

[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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

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)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9667) DefaultCacheManager inconsistent status checks

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9667?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9667: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > DefaultCacheManager inconsistent status checks > ---------------------------------------------- > > Key: ISPN-9667 > URL: https://issues.jboss.org/browse/ISPN-9667 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.2.Final > > > {{DefaultCacheManager.getTransport()}} returns {{null}} when the manager is stopping, it should not. > To make things worse, {{DefaultCacheManager.getStatus()}} returns the status of the {{GlobalComponentRegistry}}, which is still {{RUNNING}} while caches are shutting down. That means {{DCM.getTransport()}} and {{DCM.getAddress()}} return {{null}} while the cache are stopping, and breaks distributed streams on caches that are still running. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10016) Provide a default Lucene analyzer for file names

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10016?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10016: ----------------------------------- Fix Version/s: (was: 9.3.7.Final) > Provide a default Lucene analyzer for file names > ------------------------------------------------ > > Key: ISPN-10016 > URL: https://issues.jboss.org/browse/ISPN-10016 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.9.Final > > > This is generic enough to be included in the stock analyzers. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019