March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-5298: --------------------------------- If I understand correctly how expiration is supposed to work we should always be able to satisfy this condition (sync put) regardless of how small the duration/unit is: put(k, v, lifespan, unit) sleep(lifespan, unit) assert(null, get(k)) If I recall correctly expiration is checked on access. So if the clocks are in sync with delta < unit I think it should work even for multiple-host setups. Separate fields are a good option for large(r) durations with are not multiple of a second (e.g. 29day+23h+59m+59s+999ms). To reuse the existing fields their type would need to change to vLong to hold this duration in ns. > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5298: ------------------------------------ I doubt we'll ever be able to provide microsecond precision for expiration... Also, I don't think you can say a field is optional in HotRod without also adding a flag to say whether that field is present. And if we were to add a flag, I'd rather add a MILLISECOND_RESOLUTION or NANOSECOND_RESOLUTION flag instead of adding both a flag and another field. [~galder.zamarreno] WDYT? > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5195) CacheConfigurationException when two methods using default cache configuration are called in same request

by Marcio Dantas (JIRA)

[ https://issues.jboss.org/browse/ISPN-5195?page=com.atlassian.jira.plugin.... ] Marcio Dantas updated ISPN-5195: -------------------------------- Affects Version/s: 7.1.1.Final > CacheConfigurationException when two methods using default cache configuration are called in same request > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-5195 > URL: https://issues.jboss.org/browse/ISPN-5195 > Project: Infinispan > Issue Type: Bug > Components: CDI Integration > Affects Versions: 6.0.2.Final, 7.1.1.Final > Reporter: Marcio Dantas > Priority: Critical > Labels: cacheresult, cdi, infinispan, injectedcacheresolver > Attachments: infinispan-cdi.tar.gz > > > When two methods annotated with @CacheResult (without cacheName specified) are called in the same request, then the following error occurs: > {panel} > org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.infinispan.jcache.interceptor.ExpirationTrackingInterceptor] being added to the interceptor chain 1743453620 more than once! > at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76) > at org.infinispan.interceptors.InterceptorChain.addInterceptorBefore(InterceptorChain.java:248) > at org.infinispan.CacheImpl.addInterceptorBefore(CacheImpl.java:717) > at org.infinispan.jcache.JCache.addExpirationTrackingInterceptor(JCache.java:158) > at org.infinispan.jcache.JCache.<init>(JCache.java:111) > at org.infinispan.jcache.JCacheManager.configureCache(JCacheManager.java:238) > at org.infinispan.jcache.annotation.InjectedCacheResolver.getCacheFromDefaultCacheManager(InjectedCacheResolver.java:105) > at org.infinispan.jcache.annotation.InjectedCacheResolver.resolveCache(InjectedCacheResolver.java:97) > at org.infinispan.jcache.annotation.InjectedCacheResolver$Proxy$_$$_WeldClientProxy.resolveCache(InjectedCacheResolver$Proxy$_$$_WeldClientProxy.java) > at org.infinispan.jcache.annotation.AbstractCacheResultInterceptor.cacheResult(AbstractCacheResultInterceptor.java:56) > at org.infinispan.jcache.annotation.InjectedCacheResultInterceptor.cacheResult(InjectedCacheResultInterceptor.java:33) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) > at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:69) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:112) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:88) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:55) > at org.infinispan.quickstart.cdi.GreetingService$Proxy$_$$_WeldSubclass.greetDefaultCacheConfigTwo(GreetingService$Proxy$_$$_WeldSubclass.java) > at org.infinispan.quickstart.cdi.GreetingController.greet(GreetingController.java:58) > at org.infinispan.quickstart.cdi.GreetingController$Proxy$_$$_WeldClientProxy.greet(GreetingController$Proxy$_$$_WeldClientProxy.java) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.el.parser.AstValue.invoke(AstValue.java:258) > at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) > at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) > at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) > at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) > at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) > ... 21 more > {panel} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5295) Remote cache entries with sub-second lifetime never expire

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5295?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5295: ------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Ion Savin Fix Version/s: 7.2.0.Beta1 Resolution: Done > Remote cache entries with sub-second lifetime never expire > ---------------------------------------------------------- > > Key: ISPN-5295 > URL: https://issues.jboss.org/browse/ISPN-5295 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.2.0.Beta1 > > > remoteCache.put("key", "value", 999, TimeUnit.MILLISECOND) > Expected: the entry expires after 999 millis > Actual: the entry never expires > HotRod lifespan is specified with second granularity but during conversion the subsecond part is truncated: > remoteCache.put("key", "value", 1999, TimeUnit.MILLISECOND) > Expected: after 1998 millis the entry is still present > Actual: after 1000 millis the entry is expired -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-5298: --------------------------------- At the moment it might not be very useful but using the highest precision provided by TimeUnit makes the change a bit more future-proof. If in the future there's a need for higher than millisecond precision we don't need to change the HR protocol again. > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5298: ------------------------------------ Do we really want more than millisecond resolution? I doubt we can get millisecond precision with a remote distributed cache, anyway, as the write operation is very likely to take more than 1 millisecond. > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5221) Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5221?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5221: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.Beta1 Resolution: Done > Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5221 > URL: https://issues.jboss.org/browse/ISPN-5221 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Final > Environment: Infinispan 7.1.0Final > Reporter: Enrico Olivelli > Assignee: Galder Zamarreño > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > Using the LAZY nearcache (new in 7.1.0Final) when a java.net.SocketTimeoutException occurs against one of the given HotRod server the RemoteCache becames not usable any more > This happens very frequently in our DEV environment, but I cannot reproduce it inside a test case > This is the stacktrace > {code} > 15/02/13 14:51:39 ERROR event.ClientListenerNotifier: ISPN004043: Unrecoverable error reading event from server xxx.xxx.xxx/10.168.10.117:11222, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:184) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:282) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:126) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:236) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.SocketTimeoutException > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > ... 8 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5298: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3313 > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5298?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5298: ---------------------------- Status: Open (was: New) > HotRod millisecond precision for lifespan/maxidle > ------------------------------------------------- > > Key: ISPN-5298 > URL: https://issues.jboss.org/browse/ISPN-5298 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > Currently lifespan/maxidle precision is SECONDS. > JSR-107 requires MILLISECONDS precision. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5303) Move EC2 demos to their own repo

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5303?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5303: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.Beta1 Resolution: Done > Move EC2 demos to their own repo > -------------------------------- > > Key: ISPN-5303 > URL: https://issues.jboss.org/browse/ISPN-5303 > Project: Infinispan > Issue Type: Task > Components: Demos and Tutorials > Affects Versions: 7.1.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > The EC2 demos should be moved to their own repository and the binary data blobs should be removed from history to trim size -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

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 2015