August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5668) Unable to sort on numeric field that can be null

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5668?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-5668: ---------------------------------- Status: Open (was: New) > Unable to sort on numeric field that can be null > ------------------------------------------------ > > Key: ISPN-5668 > URL: https://issues.jboss.org/browse/ISPN-5668 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.0.Beta3 > Reporter: Gustavo Fernandes > > Currently {{QueryDslConditionsTest.testIsNullNumericWithProjection1}} is disabled -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5631) NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5631?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5631: ---------------------------------------- [~enrico.olivelli], as you rightly say, this is the result of the async event implementation. The idea is that the removals will eventually reach the client. It'd be very expensive for the server to block the outcome of say, a put call, until all connected clients would have consumed the event, which in the case of near caching, it'd result in a removal. > NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove > ------------------------------------------------------------------------------------------------ > > Key: ISPN-5631 > URL: https://issues.jboss.org/browse/ISPN-5631 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.2.3.Final > Environment: Java hotrod client/server > Reporter: Enrico Olivelli > Labels: hotrod-java-client > > When a Java HotRod client invalidates (remove) an entry it is possibile that this action is not propagated with enough speed to other clients due to the async nature of event notifcations used by NearCache, an so it is possibile that another client looks up a stale entry from its near cache. > A typical "writer client" scenario is: > - update the database and commit the transaction > - invalidate the entry which represents the updated (only a "remove") > The "reader" procedure is: > - lookup in the cache (nearcache, backed by the remote Infinispan cluster) > - in case of "cache miss" perform a lookup on the database and write the entry in the cache -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5607: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3641, https://github.com/infinispan/infinispan/pull/3642 > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 8.0.0.Final, 7.2.5.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5653) keySet().iterator() does not propagate flags to remove()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5653?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5653: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1252576|https://bugzilla.redhat.com/show_bug.cgi?id=1252576] from NEW to POST > keySet().iterator() does not propagate flags to remove() > -------------------------------------------------------- > > Key: ISPN-5653 > URL: https://issues.jboss.org/browse/ISPN-5653 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 8.0.0.Beta3, 7.2.4.Final, 8.0.0.Final > > > Calling {{remove()}} on iterator obtained through keySet() does not propagate flags from the original (decorated) cache. Test case (should go into BaseEntryRetrieverTest): > {code} > @Test > public void simpleTestWithFlags() { > Map<Object, String> values = putValuesInCache(); > final Cache<Object, Object> cache = cache(0, CACHE_NAME); > cache.getAdvancedCache().addInterceptor(new BaseCustomInterceptor() { > @Override > public Object visitRemoveCommand(InvocationContext ctx, RemoveCommand command) throws Throwable { > assertTrue(command.hasFlag(Flag.SKIP_CACHE_STORE)); > return super.visitRemoveCommand(ctx, command); > } > }, 0); > for (Iterator it = cache(0, CACHE_NAME).getAdvancedCache().withFlags(Flag.SKIP_CACHE_STORE).keySet().iterator(); it.hasNext();) { > assertTrue(values.containsKey(it.next())); > it.remove(); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5653) keySet().iterator() does not propagate flags to remove()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5653?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5653: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1252565, https://bugzilla.redhat.com/show_bug.cgi?id=1252576 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1252565) > keySet().iterator() does not propagate flags to remove() > -------------------------------------------------------- > > Key: ISPN-5653 > URL: https://issues.jboss.org/browse/ISPN-5653 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 8.0.0.Beta3, 7.2.4.Final, 8.0.0.Final > > > Calling {{remove()}} on iterator obtained through keySet() does not propagate flags from the original (decorated) cache. Test case (should go into BaseEntryRetrieverTest): > {code} > @Test > public void simpleTestWithFlags() { > Map<Object, String> values = putValuesInCache(); > final Cache<Object, Object> cache = cache(0, CACHE_NAME); > cache.getAdvancedCache().addInterceptor(new BaseCustomInterceptor() { > @Override > public Object visitRemoveCommand(InvocationContext ctx, RemoveCommand command) throws Throwable { > assertTrue(command.hasFlag(Flag.SKIP_CACHE_STORE)); > return super.visitRemoveCommand(ctx, command); > } > }, 0); > for (Iterator it = cache(0, CACHE_NAME).getAdvancedCache().withFlags(Flag.SKIP_CACHE_STORE).keySet().iterator(); it.hasNext();) { > assertTrue(values.containsKey(it.next())); > it.remove(); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5653) keySet().iterator() does not propagate flags to remove()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5653?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5653: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1252565|https://bugzilla.redhat.com/show_bug.cgi?id=1252565] from NEW to POST > keySet().iterator() does not propagate flags to remove() > -------------------------------------------------------- > > Key: ISPN-5653 > URL: https://issues.jboss.org/browse/ISPN-5653 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 8.0.0.Beta3, 7.2.4.Final, 8.0.0.Final > > > Calling {{remove()}} on iterator obtained through keySet() does not propagate flags from the original (decorated) cache. Test case (should go into BaseEntryRetrieverTest): > {code} > @Test > public void simpleTestWithFlags() { > Map<Object, String> values = putValuesInCache(); > final Cache<Object, Object> cache = cache(0, CACHE_NAME); > cache.getAdvancedCache().addInterceptor(new BaseCustomInterceptor() { > @Override > public Object visitRemoveCommand(InvocationContext ctx, RemoveCommand command) throws Throwable { > assertTrue(command.hasFlag(Flag.SKIP_CACHE_STORE)); > return super.visitRemoveCommand(ctx, command); > } > }, 0); > for (Iterator it = cache(0, CACHE_NAME).getAdvancedCache().withFlags(Flag.SKIP_CACHE_STORE).keySet().iterator(); it.hasNext();) { > assertTrue(values.containsKey(it.next())); > it.remove(); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5653) keySet().iterator() does not propagate flags to remove()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5653?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5653: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1252565 > keySet().iterator() does not propagate flags to remove() > -------------------------------------------------------- > > Key: ISPN-5653 > URL: https://issues.jboss.org/browse/ISPN-5653 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 8.0.0.Beta3, 7.2.4.Final, 8.0.0.Final > > > Calling {{remove()}} on iterator obtained through keySet() does not propagate flags from the original (decorated) cache. Test case (should go into BaseEntryRetrieverTest): > {code} > @Test > public void simpleTestWithFlags() { > Map<Object, String> values = putValuesInCache(); > final Cache<Object, Object> cache = cache(0, CACHE_NAME); > cache.getAdvancedCache().addInterceptor(new BaseCustomInterceptor() { > @Override > public Object visitRemoveCommand(InvocationContext ctx, RemoveCommand command) throws Throwable { > assertTrue(command.hasFlag(Flag.SKIP_CACHE_STORE)); > return super.visitRemoveCommand(ctx, command); > } > }, 0); > for (Iterator it = cache(0, CACHE_NAME).getAdvancedCache().withFlags(Flag.SKIP_CACHE_STORE).keySet().iterator(); it.hasNext();) { > assertTrue(values.containsKey(it.next())); > it.remove(); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5671) Implement missing RemoteCache read operations using near cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5671?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5671: ----------------------------------- Description: For example: getAll, getWithMetadata, containsKey, getBulk, getAsync, values, retrieveEntries, and entrySet. (was: For example: getAll, getWithMetadata, containsKey, getBulk, getAsync, values, and entrySet.) > Implement missing RemoteCache read operations using near cache > -------------------------------------------------------------- > > Key: ISPN-5671 > URL: https://issues.jboss.org/browse/ISPN-5671 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.0.0.Final > > > For example: getAll, getWithMetadata, containsKey, getBulk, getAsync, values, retrieveEntries, and entrySet. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5664) Null is returned for a not expired entry in Hot Rod client

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5664?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5664: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3640 > Null is returned for a not expired entry in Hot Rod client > ---------------------------------------------------------- > > Key: ISPN-5664 > URL: https://issues.jboss.org/browse/ISPN-5664 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.0.Beta2 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 7.2.5.Final > > > For a mortal entry (lifespan > -1), overwriting it with lifespan=-1 (make it immortal) unexpectedly removes the entry like follows. > ~~~ > cache.put(key, "value1", 100, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns "value1" > cache.put(key, "value2", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns null, expected "value2" > cache.put(key, "value3", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > cache.get(key); // returns "value3" > ~~~ > In library mode, the 2nd get returns non-null as expected. The same behaviour is observed for a transient (maxIdle > -1) entry also. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5670) Hot Rod server sets -1 for lifespan or maxIdle as default

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5670?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5670: -------------------------------- Fix Version/s: 8.0.0.CR1 > Hot Rod server sets -1 for lifespan or maxIdle as default > --------------------------------------------------------- > > Key: ISPN-5670 > URL: https://issues.jboss.org/browse/ISPN-5670 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 7.2.5.Final > > > The hotrod server currently keeps the default lifespan and maxIdle in the CacheDecodeContext. This works fine however a metadata is generated ignoring that if -1 is passed. Instead the put(K, V, Metadata) merges the default metadata into the one generated, which won't have a lifespan or maxIdle set since it was -1. In this case the merge method will take the default value instead. We should explicitly set the metadata to -1 before calling put(K, V, Metadata) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2015