June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4439) enhance asynchronous Hot Rod putAllAsync method

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-4439: -------------------------------------- Summary: enhance asynchronous Hot Rod putAllAsync method Key: ISPN-4439 URL: https://issues.jboss.org/browse/ISPN-4439 Project: Infinispan Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha4 Reporter: Wolf-Dieter Fink Assignee: Mircea Markus The current implementation of the method putAllAsync(...) within the Hot Rod client simple use the putAll(...) method which simple iterate over the given Map and use put(...) for each entry synchrounous. Therefore it takes a longer time to put all entries into the cache. A simple loop which calls putAsync for each entry has a significant improvement. i.e. with 100,000 entries the over all duration is 15 times faster -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4291: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1111188|https://bugzilla.redhat.com/show_bug.cgi?id=1111188] from NEW to ASSIGNED > Poor REPL state transfer performance with cache stores > ------------------------------------------------------ > > Key: ISPN-4291 > URL: https://issues.jboss.org/browse/ISPN-4291 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > > During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node. > This is an extremely slow operation, and doesn't even make sense for a REPL cache. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4426) Transaction replayed but not committed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4426?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4426: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1111644|https://bugzilla.redhat.com/show_bug.cgi?id=1111644] from NEW to ASSIGNED > Transaction replayed but not committed > -------------------------------------- > > Key: ISPN-4426 > URL: https://issues.jboss.org/browse/ISPN-4426 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 63gablocker > > Dist TX cache, node C is joining. In previous topology, entry is owned by A (primary) and B (backup). In new topology, primary ownership is transferred to C, B stays backup. > 1. TX is prepared in old topology and is being committed, when topology changes > 2. on C (the new owner), the TX info is received and later even the old entry > 3. C receives the CommitCommand, therefore, it correctly replays the PrepareCommand. > 4. When the entries are about to be committed, in TxInterceptor the transaction is found to be already completed as it has lower TxID. > Result: the transaction is not being executed and stale data stay on the node (with my algortihm it eventually led to complete entry loss). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4112) RHQ library plugin: restart cache -- availability report DOWN but cache running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4112?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4112: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1076486|https://bugzilla.redhat.com/show_bug.cgi?id=1076486] from POST to MODIFIED > RHQ library plugin: restart cache -- availability report DOWN but cache running > ------------------------------------------------------------------------------- > > Key: ISPN-4112 > URL: https://issues.jboss.org/browse/ISPN-4112 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX, reporting and management > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: William Burns > Labels: 63gablocker > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > When we explicitly call STOP operation on particular cache using RHQ UI, this operation is successfully issued and cache is stopped. > Then, we can issue START operation as well. > Cache is started but RHQ is still not-correctly reporting that cache is DOWN and unavailable. > I will investigate this issue, this is just for proper heads up and for tracking purposes. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4414) RequestBalancingStrategy nextServer should be evolved in a backwards compatible way

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4414?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4414: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096877|https://bugzilla.redhat.com/show_bug.cgi?id=1096877] from NEW to ASSIGNED > RequestBalancingStrategy nextServer should be evolved in a backwards compatible way > ----------------------------------------------------------------------------------- > > Key: ISPN-4414 > URL: https://issues.jboss.org/browse/ISPN-4414 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 7.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > In ISPN-3942, we changed RequestBalancingStrategy's nextServer() to receive a list of failed servers. This could be problematic for end users. Find a better, backwards compatible way to deal with this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2956: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: 63gablocker, hotrod-java-client, remote-clients > Fix For: 7.0.0.Beta1 > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4438) Entry is not properly unmarshalled in compatibility mode when L1 enabled

by Martin Gencur (JIRA)

Martin Gencur created ISPN-4438: ----------------------------------- Summary: Entry is not properly unmarshalled in compatibility mode when L1 enabled Key: ISPN-4438 URL: https://issues.jboss.org/browse/ISPN-4438 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha4 Reporter: Martin Gencur Assignee: Martin Gencur Fix For: 7.0.0.Alpha5 When a distributed cache is used together with compatibility mode and L1 is enabled. The entry being returned to the client is not unmarshalled when it is found in the L1 cache. Unmarshalling works fine if the entry is retrieved from a remote node (not found in L1). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4438) Entry is not properly unmarshalled in compatibility mode when L1 enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4438?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4438: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1112886 > Entry is not properly unmarshalled in compatibility mode when L1 enabled > ------------------------------------------------------------------------ > > Key: ISPN-4438 > URL: https://issues.jboss.org/browse/ISPN-4438 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When a distributed cache is used together with compatibility mode and L1 is enabled. The entry being returned to the client is not unmarshalled when it is found in the L1 cache. Unmarshalling works fine if the entry is retrieved from a remote node (not found in L1). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4437) L1 cache is enabled by default in server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4437?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4437: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1112886 > L1 cache is enabled by default in server > ---------------------------------------- > > Key: ISPN-4437 > URL: https://issues.jboss.org/browse/ISPN-4437 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When a distributed cache is used in the server, L1 cache is enabled and the lifespan is 10 mins even if L1 is not configured in standalone.xml file. > This is not an expected behaviour and should be changed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4437) L1 cache is enabled by default in server

by Martin Gencur (JIRA)

Martin Gencur created ISPN-4437: ----------------------------------- Summary: L1 cache is enabled by default in server Key: ISPN-4437 URL: https://issues.jboss.org/browse/ISPN-4437 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Affects Versions: 7.0.0.Alpha4 Reporter: Martin Gencur Assignee: Martin Gencur Fix For: 7.0.0.Alpha5 When a distributed cache is used in the server, L1 cache is enabled and the lifespan is 10 mins even if L1 is not configured in standalone.xml file. This is not an expected behaviour and should be changed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014