December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5052) Lock timeout details prints out null for local locks

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5052?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5052: ------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Erik Salter Fix Version/s: 7.1.0.Beta1 Resolution: Done > Lock timeout details prints out null for local locks > ---------------------------------------------------- > > Key: ISPN-5052 > URL: https://issues.jboss.org/browse/ISPN-5052 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Erik Salter > Assignee: Erik Salter > Priority: Trivial > Fix For: 7.1.0.Beta1 > > > Here's a trivial thing: if the context's origin is local, the lock timeout message will out null for the "while request came from" part. (The address for the origin is set only for remote transactions). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5059: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3150 > JGroups subsystem doesn't support Vault > --------------------------------------- > > Key: ISPN-5059 > URL: https://issues.jboss.org/browse/ISPN-5059 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > > JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration: > {noformat} > <protocol type="ENCRYPT"> > <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property> > <property name="store_password">${VAULT::keystore::password::1}</property> > <property name="alias">memcached</property> > </protocol> > {noformat} > i.e. it uses Vault-encrypted password for keystore, it fails with: > {noformat} > groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55] > Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309) > at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) > at org.jgroups.JChannel.init(JChannel.java:848) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87) > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69) > {noformat} > Vault record for {{keystore::password}} exists: > {noformat} > Task: Verify whether a secured attribute exists > Enter Vault Block:keystore > Enter Attribute Name:password > A value exists for (keystore, password) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5072) MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5072?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5072: -------------------------------- Status: Open (was: New) > MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer > ----------------------------------------------------------------------------- > > Key: ISPN-5072 > URL: https://issues.jboss.org/browse/ISPN-5072 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > The MapExternalizer originally extended InstanceReusingAdvancedExternalizer to allow for the CacheStatusResponse class to properly reuse values. However with ISPN-3561 we no longer use just a Map but also a ManagerStatusResponse so we only need the Externalizer for that class to extend InstanceReusingAdvancedExternalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5072) MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5072?page=com.atlassian.jira.plugin.... ] Work on ISPN-5072 started by William Burns. ------------------------------------------- > MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer > ----------------------------------------------------------------------------- > > Key: ISPN-5072 > URL: https://issues.jboss.org/browse/ISPN-5072 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Alpha1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > The MapExternalizer originally extended InstanceReusingAdvancedExternalizer to allow for the CacheStatusResponse class to properly reuse values. However with ISPN-3561 we no longer use just a Map but also a ManagerStatusResponse so we only need the Externalizer for that class to extend InstanceReusingAdvancedExternalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5072) MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer

by William Burns (JIRA)

William Burns created ISPN-5072: ----------------------------------- Summary: MapExternalizer no longer needs to extend InstanceReusingAdvancedExternalizer Key: ISPN-5072 URL: https://issues.jboss.org/browse/ISPN-5072 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 7.1.0.Alpha1 Reporter: William Burns Assignee: William Burns Fix For: 7.1.0.Beta1, 7.1.0.Final The MapExternalizer originally extended InstanceReusingAdvancedExternalizer to allow for the CacheStatusResponse class to properly reuse values. However with ISPN-3561 we no longer use just a Map but also a ManagerStatusResponse so we only need the Externalizer for that class to extend InstanceReusingAdvancedExternalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3811: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1040046|https://bugzilla.redhat.com/show_bug.cgi?id=1040046] from ON_QA to VERIFIED > Initial ST leaves node as member without data after MERGE > --------------------------------------------------------- > > Key: ISPN-3811 > URL: https://issues.jboss.org/browse/ISPN-3811 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet). > During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him. > Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4222) Add support for distributed entry iterator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4222?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4222: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1099969|https://bugzilla.redhat.com/show_bug.cgi?id=1099969] from ON_QA to VERIFIED > Add support for distributed entry iterator > ------------------------------------------ > > Key: ISPN-4222 > URL: https://issues.jboss.org/browse/ISPN-4222 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > ISPN-4068 requires the need of being able to iterate over all entries found in the cache, irrespective of it is a distributed cache and with or without a loader/store. This jira is to cover adding that support. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-4949: -------------------------------- OK, so are the steps as follows: ? * A invokes a prepare(ABC) with a timeout of 4 mins * A and B reply * C also replies after the GC is over --> The new topology is installed. Thanks for the clarification ! > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4949: ------------------------------------ To clarify, the timeout is just for the prepare RPC. If a node fails to reply in 4 minutes, we keep using the old cache topology as long as nothing else happens (e.g. a JGroups view change, or a node joining/leaving at the cache level). I wouldn't expect any user to wait for a node to be suspected for > 1 minute, because all read/write operations involving that node will be blocked during that time, so 4 minutes should be enough to make sure we always get a new view (or an ACK). > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4847) Improve indexing performance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4847?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4847: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1130447|https://bugzilla.redhat.com/show_bug.cgi?id=1130447] from ASSIGNED to ON_QA > Improve indexing performance > ---------------------------- > > Key: ISPN-4847 > URL: https://issues.jboss.org/browse/ISPN-4847 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Lucene Directory > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > Assignee: Sanne Grinovero > Priority: Critical > > This JIRA is focused on optimizing performance of use case where the application uses short or none transactions - therefore, no batching can be applied - and then performs the query and expects that the result will be consistent (please, specify in documentation if any lag after cache.put() or tx.commit() is required and if the application can detect that the update has been applied). > We are well aware (see BZ) that indexing can be implemented with very low overhead, but the throughput is thousands of times lower [1] (configuration in [2]) with distributed mode storing index in replicated cache, and about 4x slowdown when comparing replicated cache without indexing and indexing to NRT FS/RAM. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-query-index... -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 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 December 2014