August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5135) Configure server locking/statetransfer/etc from JON plugin

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5135?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5135: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Configure server locking/statetransfer/etc from JON plugin > ---------------------------------------------------------- > > Key: ISPN-5135 > URL: https://issues.jboss.org/browse/ISPN-5135 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 8.1.0.Final > > > When creating a new cache using the JON plugin in a server, it is not possible to modify locking and statetransfer dynamically (without restarting the server instance). We should allow that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5076: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Pessimistic transactions can lose their locks when the primary owner changes > ---------------------------------------------------------------------------- > > Key: ISPN-5076 > URL: https://issues.jboss.org/browse/ISPN-5076 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 7.0 > Fix For: 8.1.0.Final > > > In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v)}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s). > If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5093) Granularity of remote event listener implementations doing the same job

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5093?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5093: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Granularity of remote event listener implementations doing the same job > ----------------------------------------------------------------------- > > Key: ISPN-5093 > URL: https://issues.jboss.org/browse/ISPN-5093 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final > > > Currently, if N clients add the same listener to a cache that does the same job, e.g. keeping a near cache consistent, this results in N server-side cluster listeners created, each potentially installed in different nodes. If one of those nodes fails, all clients that had a listener registered to that node will have to find a different node for this listener. > The downsides of this approach is that there are as many cluster listeners installed as clients have added listeners (or have near cache enabled), which might not very efficient. If a node goes down, all clients that have cluster listeners there need to failover to some other node. > The advantage of this approach is simplicity of the approach to decide where to add the listener and where to failover to. > For this type of scenarios, an alternative set up might be worth exploring: > If all these client side listeners are interested in exactly the same events, and the client ID would be exposed via the RemoteCache API, a server side cluster listener multi-plexing between all these clients could be potentially built. In other words, instead of having N clients register N cluster listeners, the first client would register the cluster listener with a client listener ID, and if more registrations were added with the same client listener ID, the connections would be added to the existing cluster listener implementation. > The maximise the efficiency of this solution, all clients (even running in different JMVs), given the same client listener ID, should agree upon the node to add the listener in. For a distributed cache, hashing on the cache name would work. For replicated caches, since there's no hashing available, the first node of the view could be used. > Since the logic to be executed server-side varies between being the first node adding the client listener vs the others, synchronization would be added to make sure that the first invocation only creates the cluster listener, and the others simply add the channel to the listener. > Failover is a bit more tricky too, because if the node with the cluster listener goes down, all the clients have to failover, which again exposes a 1st vs the others type of logic. > Advantages of this approach is the reduction in number of cluster listeners and potentially efficiency coming from a single cluster listener implementation server side. > The disadvantages come from the server side logic to add/failover a cluster listener, which need to take into account if the listener is present or not. Other disadvantages come from needing the clients to use some specific routing for adding listeners for same node. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5042) Remote gets caused by writes could be replicated only to the primary owner

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5042?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5042: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Remote gets caused by writes could be replicated only to the primary owner > -------------------------------------------------------------------------- > > Key: ISPN-5042 > URL: https://issues.jboss.org/browse/ISPN-5042 > Project: Infinispan > Issue Type: Enhancement > Components: Core, State Transfer > Affects Versions: 7.1.0.Alpha1 > Reporter: Dan Berindei > Priority: Minor > Labels: 7.0 > Fix For: 8.1.0.Final > > > For write operations that need the previous value, a write CH-only owner that doesn't have a key locally will attempt to retrieve the key from the read CH-owners. > Sending the remote get command to all the previous owners will create extra load on the cluster during state transfer, so it should be more efficient to send the remote get only to the primary owner. Even though the latency of some write operations will be higher, the average latency should be better. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5067) CLI for server docs need updating to reflect WildFly base

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5067?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5067: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > CLI for server docs need updating to reflect WildFly base > --------------------------------------------------------- > > Key: ISPN-5067 > URL: https://issues.jboss.org/browse/ISPN-5067 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Servers > Affects Versions: 7.1.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5073) Improve "Number of Entries" stats

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5073?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5073: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Improve "Number of Entries" stats > --------------------------------- > > Key: ISPN-5073 > URL: https://issues.jboss.org/browse/ISPN-5073 > Project: Infinispan > Issue Type: Task > Components: Core, JMX, reporting and management > Affects Versions: 7.1.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > Fix For: 8.1.0.Final > > > Currently the getNumberOfEntries in CacheMgmtInterceptor returns the size of the datacontainer which doesn't take into account expired entries and cache stores. > To avoid compatibility issues, modify the description to reflect its behaviour and add proper statistics, possibly with different flag combinations (SKIP_REMOTE, SKIP_CACHE_LOAD) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5238) Maintain session in ispn-mgmt-console (ctrl+R)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5238?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5238: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Maintain session in ispn-mgmt-console (ctrl+R) > ---------------------------------------------- > > Key: ISPN-5238 > URL: https://issues.jboss.org/browse/ISPN-5238 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Tomas Sykora > Assignee: Vladimir Blagojevic > Fix For: 8.1.0.Final > > > When you reload a page in Infinispan Management Console data is lost and you need to re-login. We need to make sure that the session is maintained properly and operations like ctrl+R, F5 etc. does not affect behaviour negatively. > It will also help with development and testing when you need to reload a page to see some changes from time to time. > I did a small research around this topic and made some experiments but I was not able to achieve what I wanted. Maybe we can come up with even different approach. > Anyway I suppose we can stick to the idea that ctrl+R should just reload the page and data successfully. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5235) Implement node details page (P1)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5235?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5235: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Implement node details page (P1) > -------------------------------- > > Key: ISPN-5235 > URL: https://issues.jboss.org/browse/ISPN-5235 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 8.1.0.Final > > > In our admin console current node details page does not contain the following functionality that should be implemented: > * All real-time metrics > * -Cache list- > * Cache filter > * Node availability -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5211) NPE on NumericVersionGenerator.start() when JGroups configuration resource not found

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5211?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5211: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > NPE on NumericVersionGenerator.start() when JGroups configuration resource not found > ------------------------------------------------------------------------------------ > > Key: ISPN-5211 > URL: https://issues.jboss.org/browse/ISPN-5211 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Sanne Grinovero > Fix For: 8.1.0.Final > > > This is easy to reproduce: start a {{CacheManager}} which has a {{Transport}} configured with a non-existent resource name for the JGroups configuration. > Would be great to have a better error message. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5233) Implement clusters view page (P1)

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5233?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5233: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Implement clusters view page (P1) > --------------------------------- > > Key: ISPN-5233 > URL: https://issues.jboss.org/browse/ISPN-5233 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 8.1.0.Final > > > In our admin console the current clusters view page contains a list of available clusters. However, we are missing the number of nodes and caches per cluster. We also automatically append state "Available" while in fact we should check for clusters availability and set it accordingly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2015