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

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