October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4446) removeCache fails for caches with a SingleFileStore

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4446?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4446: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > removeCache fails for caches with a SingleFileStore > --------------------------------------------------- > > Key: ISPN-4446 > URL: https://issues.jboss.org/browse/ISPN-4446 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Reporter: Jim Crossley > Assignee: Galder Zamarreño > Fix For: 7.0.0.CR1, 7.0.0.Final > > > If DefaultCacheManager.isRunning("foo") returns true, and "foo" has an associated SingleFileStore, calling DefaultCacheManager.removeCache("foo") tosses an NPE and isRunning("foo") continues to return true, even though the cache is in a TERMINATED state. I can avoid the NPE by stopping the cache before calling removeCache, but isRunning will still incorrectly return true. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4633) Local transaction not removed from transaction table after a size() operation

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4633?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-4633: ------------------------------------- [~pferraro] Do you need this fix backported? > Local transaction not removed from transaction table after a size() operation > ----------------------------------------------------------------------------- > > Key: ISPN-4633 > URL: https://issues.jboss.org/browse/ISPN-4633 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Executing cache.size() as the only operation during a transaction will leave behind a LocalTransaction in the transaction table. This tx has not locked keys and will eventually be removed by the reaper after a while. The same fix as for ISPN-4196 should be applied for size(). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4734) Hot Rod marshaller for custom events...etc, needs to be configurable in server

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4734?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4734: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Final Resolution: Done > Hot Rod marshaller for custom events...etc, needs to be configurable in server > ------------------------------------------------------------------------------ > > Key: ISPN-4734 > URL: https://issues.jboss.org/browse/ISPN-4734 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.Beta2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.CR1, 7.0.0.Final > > > The marshaller used by Hot Rod to marshall custom events is configurable via HotRodServerConfigurationBuilder. This needs to be extended to server side configuration. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4470) cache.keySet().size() returns different value than cache.size() for HotRod client

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4470?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4470: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > cache.keySet().size() returns different value than cache.size() for HotRod client > --------------------------------------------------------------------------------- > > Key: ISPN-4470 > URL: https://issues.jboss.org/browse/ISPN-4470 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.CR1, 7.0.0.Final > > > cache.keySet().size() returns the number of all keys in the cluster (even a distributed one) while cache.size() returns just local cache size (this might be different for a distributed cache) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4736) Add size() operation to Hot Rod

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4736?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4736: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add size() operation to Hot Rod > ------------------------------- > > Key: ISPN-4736 > URL: https://issues.jboss.org/browse/ISPN-4736 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.CR1, 7.0.0.Final > > > This jira is a spin-off of https://github.com/infinispan/infinispan/pull/2780, resulting from the feedback/comments provided by Will, Dan and Sanne. > Essentially, what ISPN-4470 tries to do is provide a RemoteCache.size() implementation. The first implementation simply computed the keySet() and got its size. This is clearly not optimal since you're bringing a load of keys to not use them at all. > The second solution used statistics of different nodes to calculate number of total keys in the cluster, and if statistics were disabled, fallback on keySet(). The problem here is that statistics don't take cache store contents into account but keySet() does, which would be confusing for the user. Having such size related statistics check persistent stores would affect performance of stats. > In the end, the best way to achieve this is by implementing a new size operation on Hot Rod that calculates the total number of keys without actually bringing keys back to clients. This new operation will be part of Hot Rod 2.0. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4633) Local transaction not removed from transaction table after a size() operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4633?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4633: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1147634|https://bugzilla.redhat.com/show_bug.cgi?id=1147634] from POST to MODIFIED > Local transaction not removed from transaction table after a size() operation > ----------------------------------------------------------------------------- > > Key: ISPN-4633 > URL: https://issues.jboss.org/browse/ISPN-4633 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Executing cache.size() as the only operation during a transaction will leave behind a LocalTransaction in the transaction table. This tx has not locked keys and will eventually be removed by the reaper after a while. The same fix as for ISPN-4196 should be applied for size(). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) Cross-Site Replication: State Transfer between sites

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2342: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1148378|https://bugzilla.redhat.com/show_bug.cgi?id=1148378] from POST to MODIFIED > Cross-Site Replication: State Transfer between sites > ---------------------------------------------------- > > Key: ISPN-2342 > URL: https://issues.jboss.org/browse/ISPN-2342 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Affects Versions: 6.0.1.Final > Reporter: Erik Salter > Assignee: Pedro Ruivo > Labels: roadmap > Fix For: 7.0.0.CR1, 7.0.0.Final > > > To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys. > Note that initially, this should a manual process that is invoked on one site to one of its configured backups. > This should be based on the non-blocking state transfer mechanism for consistency. > The pseudo-design may look similar to the following: > - Manually invokable, background thread > - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner. > - Iterate through the key set. > - If the key has already been modified since the process started, discard. > - Else synchronously write the key value in a TX context -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4795) Warning message about forcing to return previous does not apply to Get operations

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4795: -------------------------------------- Summary: Warning message about forcing to return previous does not apply to Get operations Key: ISPN-4795 URL: https://issues.jboss.org/browse/ISPN-4795 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Final {code} 'ISPN006010: Operation 'GetRequest' forced to return previous value should be used on transactional caches' in the log {code} That message should not appear. GetRequest does not force returning previous. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4790) Protostream must be able to compile the schemas incrementally

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4790?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4790: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/protostream/pull/8 > Protostream must be able to compile the schemas incrementally > ------------------------------------------------------------- > > Key: ISPN-4790 > URL: https://issues.jboss.org/browse/ISPN-4790 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Affects Versions: 7.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Methods from SerializationContext currently expect a self-contained FileDescriptorSource that has all the needed depencies so it can be parsed and resolved in one go. This limitation should be lifted so users can compile incrementally. Files that cannot be compiled due to missing dependencies should be ignored in current step until future invocations. A callback mechanism could be used to deliver the actual status of the compilation to the caller instead of throwing exceptions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4790) Protostream must be able to compile the schemas incrementally

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4790?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4790: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Protostream must be able to compile the schemas incrementally > ------------------------------------------------------------- > > Key: ISPN-4790 > URL: https://issues.jboss.org/browse/ISPN-4790 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Affects Versions: 7.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Methods from SerializationContext currently expect a self-contained FileDescriptorSource that has all the needed depencies so it can be parsed and resolved in one go. This limitation should be lifted so users can compile incrementally. Files that cannot be compiled due to missing dependencies should be ignored in current step until future invocations. A callback mechanism could be used to deliver the actual status of the compilation to the caller instead of throwing exceptions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2014