July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1403) Optimise sending Hot Rod topology updates for distributed caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1403?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1403: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Optimise sending Hot Rod topology updates for distributed caches > ---------------------------------------------------------------- > > Key: ISPN-1403 > URL: https://issues.jboss.org/browse/ISPN-1403 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Cache, Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Right now, whenever a Hot Rod client sends a request with a view id which is different to the one on the server, it'd get a brand new view in the response to the request. This could be optimised nicely by only sending back a new view id when the server discovers that the client is using an inefficient view. For example, in distributed caches, the moment it gets a request for a key which lands on a node that does not own the key, it could decide to send back the view. > This would reduce the number of times the view is returned, hence improving the performance of requests. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2587) Optimize command forwarding after topology changes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2587?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2587: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Optimize command forwarding after topology changes > -------------------------------------------------- > > Key: ISPN-2587 > URL: https://issues.jboss.org/browse/ISPN-2587 > Project: Infinispan > Issue Type: Task > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Dan Berindei > > When a node receives a command with a topology id lower than its own topology id, it forwards the command to all the owners in the current topology. > This is especially bad in replicated caches, where all the nodes check whether to forward or not, and after a join we may get {{n * (n-1)}} forwarded commands instead of just {{n}}. > Most of the time the difference between the current topology id and the command's topology id is <= 1, so we could avoid a lot of the extra forwarding if we kept the previous cache topology and we forwarded the command only to the owners added in the latest topology. Obviously, if the command is older we'd still forward it to all the owners. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2491) Order of locks in optimistic locking is not strict

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2491?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2491: ------------------------------------- [~rvansa] do you feel like giving it a try? :-) > Order of locks in optimistic locking is not strict > -------------------------------------------------- > > Key: ISPN-2491 > URL: https://issues.jboss.org/browse/ISPN-2491 > Project: Infinispan > Issue Type: Quality Risk > Components: Locking and Concurrency > Affects Versions: 5.1.8.Final, 5.2.0.Beta3 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > In OptimisticLockingInterceptor, the keys are ordered according to their hash. However, the hashes can still collide, which may result in a deadlock if two keys with identical hash (only 32-bit) are sorted to different order. We should try to check if the keys are Comparable or let user provide some comparator class in config, and use the compare of hash only as the last resort. > In all cases, a warning should be emitted if the compare operation had non-strict result. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2044) Optimize marshalling of EnumSet<Flag>

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2044?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2044: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Optimize marshalling of EnumSet<Flag> > ------------------------------------- > > Key: ISPN-2044 > URL: https://issues.jboss.org/browse/ISPN-2044 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Reporter: Sanne Grinovero > Assignee: Galder Zamarreño > > When marshalling Flags, it looks like we could encode the whole EnumSet as a bitset, or use a different Marshaller ID for the empty enumset (which I'm assuming is a common case so worth optimizing for) > See also thread: http://lists.jboss.org/pipermail/infinispan-dev/2012-May/010635.html -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2491) Order of locks in optimistic locking is not strict

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2491?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2491: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Order of locks in optimistic locking is not strict > -------------------------------------------------- > > Key: ISPN-2491 > URL: https://issues.jboss.org/browse/ISPN-2491 > Project: Infinispan > Issue Type: Quality Risk > Components: Locking and Concurrency > Affects Versions: 5.1.8.Final, 5.2.0.Beta3 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Minor > > In OptimisticLockingInterceptor, the keys are ordered according to their hash. However, the hashes can still collide, which may result in a deadlock if two keys with identical hash (only 32-bit) are sorted to different order. We should try to check if the keys are Comparable or let user provide some comparator class in config, and use the compare of hash only as the last resort. > In all cases, a warning should be emitted if the compare operation had non-strict result. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1539) Optimisation: reduce the number of RPCs when L1 is enabled (default)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1539?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1539. --------------------------------- Fix Version/s: (was: 6.0.0.Final) Resolution: Duplicate Issue ISPN-317 covers this already. > Optimisation: reduce the number of RPCs when L1 is enabled (default) > -------------------------------------------------------------------- > > Key: ISPN-1539 > URL: https://issues.jboss.org/browse/ISPN-1539 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.0.1.FINAL > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: optimization, performance > > cache.put(k,v) does a remote get(1st RPC) and an put(2nd RPC) to the same remote node. This can be merged into a single RPC. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-791) On node startup, ensure all peers have compatible configurations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-791?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-791: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > On node startup, ensure all peers have compatible configurations > ---------------------------------------------------------------- > > Key: ISPN-791 > URL: https://issues.jboss.org/browse/ISPN-791 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > > This is to prevent caches that are supposed to be symmetric/identical from being misconfigured. Some elements are allowed to be unique, of course, such as bind addresses in JGroups as well as node names, server hints, certain props passed to cache stores, etc. > A simple test could be a hash (MD5 or SHA1?) of the config XML (or a serial form of the generated Configuration bean) which is exchanged as a part of the join method. On failure of the hash check, the entire object could be checked, and if that fails as well, an appropriate ConfigurationException could be thrown. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-701: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-701 > URL: https://issues.jboss.org/browse/ISPN-701 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Trustin Lee > Assignee: Tristan Tarrant > Labels: jdbc > > The current JDBC {{CacheStore}} implementation has the following shortcomings: > * poor support for vendor specific queries (e.g. MySQL's replace into) > * complex configuration is required to support the key types that cannot be converted to a String easily. > To address this issue: > * Introduce a single unified JDBC {{CacheStore}} implementation. > * Support an arbitrary key type as long as it can be serialized via {{Marshaller}}. > * Support both text and binary key. > * Encode the binary key into a text key using an efficient text encoding if the target database doesn't support binary key column. > * Provide much more flexibility in supporting vendor specific extensions. Let the user extend our {{CacheStore}} implementation and override the DB access (no more TableManipulation). > Once implemented, the existing JDBC {{CacheStore}} could be deprecated. > Configuring this would be, for example, {{GenericJdbcCacheStore}} which would have no vendor-specific optimisations, and {{MySqlJdbcCacheStore}} (subclasses {{GenericJdbcCacheStore}}) which would contain MySQL specific optimisations, etc. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-470: ------------------------------- Labels: jdg62 (was: ) > Native Hot Rod client for C++ > ----------------------------- > > Key: ISPN-470 > URL: https://issues.jboss.org/browse/ISPN-470 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit > Reporter: Manik Surtani > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Final > > Attachments: straw.patch > > > C++ client impl for HotRod. Protocol is documented here: > http://community.jboss.org/wiki/HotRodProtocol > Could be based off the Java reference impl client: > https://github.com/infinispan/infinispan/tree/master/client/hotrod-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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-470: ------------------------------- Priority: Blocker (was: Major) > Native Hot Rod client for C++ > ----------------------------- > > Key: ISPN-470 > URL: https://issues.jboss.org/browse/ISPN-470 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Environment: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit, RHEL 5, 64-bit > Reporter: Manik Surtani > Priority: Blocker > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > Attachments: straw.patch > > > C++ client impl for HotRod. Protocol is documented here: > http://community.jboss.org/wiki/HotRodProtocol > Could be based off the Java reference impl client: > https://github.com/infinispan/infinispan/tree/master/client/hotrod-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, 9 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 July 2013