October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3588) CacheManager.startCaches ignores exceptions if cache fails to start

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3588: --------------------------------- Summary: CacheManager.startCaches ignores exceptions if cache fails to start Key: ISPN-3588 URL: https://issues.jboss.org/browse/ISPN-3588 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.CR1 Reporter: Pedro Ruivo Assignee: Mircea Markus Fix For: 6.0.0.Final, 6.1.0.Final {code}startCaches(){code} creates a thread for each cache name and if a cache fails to start, the invoker is never notified and the start count down latch is released. the result is the application using the cache without be aware of the fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3443: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1001634|https://bugzilla.redhat.com/show_bug.cgi?id=1001634] from ASSIGNED to MODIFIED > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3373) HotRod topology cache should allow disabling awaitInitialTransfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3373?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3373: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED > HotRod topology cache should allow disabling awaitInitialTransfer > ----------------------------------------------------------------- > > Key: ISPN-3373 > URL: https://issues.jboss.org/browse/ISPN-3373 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols, Server > Affects Versions: 6.0.0.Alpha1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha2 > > > When a server with a hotrod endpoint joins a cluster where state transfer has been disabled (ISPN-3140), waiting for initial state transfer should also be disabled on the topology cache, otherwise failures occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3140: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED > JMX operation to suppress state transfer > ---------------------------------------- > > Key: ISPN-3140 > URL: https://issues.jboss.org/browse/ISPN-3140 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Dan Berindei > Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final > > > This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default. > The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be: > 1) Shut down application requests to the data grid > 2) Suppress state transfer on all nodes via JMX > 3) Bring down all nodes > 4) Perform maintenance work > 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX. > 6) Once all nodes are up, enable state transfer for each node again via JMX > 7) Allow application requests to reach the grid again. > The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down). > This is a small but useful subset of full manual state transfer as defined in ISPN-1394. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2763) Verify cache used for index storage is not defining any expiry

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2763?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2763: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks! > Verify cache used for index storage is not defining any expiry > -------------------------------------------------------------- > > Key: ISPN-2763 > URL: https://issues.jboss.org/browse/ISPN-2763 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > Apparently we don't fail fast if Expiry is enabled on the chache used to store a Lucene Directory. I think the Directory implementation should check for this and fail eagerly with an appropriate error message. > https://forum.hibernate.org/posting.php?mode=reply&f=9&t=1025238 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3570) Server state transfer ignores awaitInitialStateTransfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3570?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3570: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED > Server state transfer ignores awaitInitialStateTransfer > ------------------------------------------------------- > > Key: ISPN-3570 > URL: https://issues.jboss.org/browse/ISPN-3570 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3584) JGroups subsystem XSD erroneously forgets about <relay> properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3584?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3584: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1015409|https://bugzilla.redhat.com/show_bug.cgi?id=1015409] from ASSIGNED to MODIFIED > JGroups subsystem XSD erroneously forgets about <relay> properties > ------------------------------------------------------------------ > > Key: ISPN-3584 > URL: https://issues.jboss.org/browse/ISPN-3584 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3385) Move leveldb cache store to its own repository

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3385?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3385: ---------------------------------- Fix Version/s: (was: 6.0.0.CR1) > Move leveldb cache store to its own repository > ---------------------------------------------- > > Key: ISPN-3385 > URL: https://issues.jboss.org/browse/ISPN-3385 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ] William Burns updated ISPN-825: ------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Consider staggering remote get requests when using DIST > ------------------------------------------------------- > > Key: ISPN-825 > URL: https://issues.jboss.org/browse/ISPN-825 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Critical > Labels: optimization, performance > Fix For: 6.0.0.Final > > > In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. > The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. > A solution around this could be based on either (or both) of: > * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. > * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. > Needs careful thought and design. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-1855: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Accessing a non-distributed cache from a RemoteCacheManager can break topology updates > -------------------------------------------------------------------------------------- > > Key: ISPN-1855 > URL: https://issues.jboss.org/browse/ISPN-1855 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.1.1.FINAL > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode). > If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches. > Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 October 2013