August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6910) Random failures due to MagicKey

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6910?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-6910 at 8/12/16 8:07 AM: ------------------------------------------------------------- [~rvansa] I guess it depends on what you expect {{MagicKey}} to do... if you want to generate a few keys per test, and you only had a low number of nodes, the chances of failing to generate a key are miniscule. I agree that the error message is pretty bad, but almost every time when 1000 iterations are not enough, it means there's no segment with the combination of owners you want. If, however, you want to generate >10 keys, then I'd argue you don't really want {{MagicKey}}. You'd be much better served by writing a custom {{ConsistentHashFactory}} and/or {{KeyPartitioner}} that put every key in a particular segment, and assign that segment to the intended owners. was (Author: dan.berindei): [~rvansa] I guess it depends on what you expect {{MagicKey}} to do... if you want to generate a few keys per test, and you only had a low number of nodes, the chances of failing to generate a key are miniscule. I agree that the error message is pretty bad, but almost every when 1000 iterations are not enough, it means there's no segment with the combination of owners you want. If, however, you want to generate >10 keys, then I'd argue you don't really want {{MagicKey}}. You'd be much better served by writing a custom {{ConsistentHashFactory}} and/or {{KeyPartitioner}} that put every key in a particular segment, and assign that segment to the intended owners. > Random failures due to MagicKey > ------------------------------- > > Key: ISPN-6910 > URL: https://issues.jboss.org/browse/ISPN-6910 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core > Affects Versions: 9.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > There is a fixed 1000-iteration loop to find out proper key. In tests that create many magic keys, the cumulative probability of failing one of the keys' generation is going up and this is causing random failures in the testsuite. > Moreover, the equality of magic keys is based only on the hashCode - with many keys, there is a non-trivial chance that the hashcodes will make two logically different keys equal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6910) Random failures due to MagicKey

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6910?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6910: ------------------------------------ [~rvansa] I guess it depends on what you expect {{MagicKey}} to do... if you want to generate a few keys per test, and you only had a low number of nodes, the chances of failing to generate a key are miniscule. I agree that the error message is pretty bad, but almost every when 1000 iterations are not enough, it means there's no segment with the combination of owners you want. If, however, you want to generate >10 keys, then I'd argue you don't really want {{MagicKey}}. You'd be much better served by writing a custom {{ConsistentHashFactory}} and/or {{KeyPartitioner}} that put every key in a particular segment, and assign that segment to the intended owners. > Random failures due to MagicKey > ------------------------------- > > Key: ISPN-6910 > URL: https://issues.jboss.org/browse/ISPN-6910 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite - Core > Affects Versions: 9.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Beta1, 9.0.0.Final > > > There is a fixed 1000-iteration loop to find out proper key. In tests that create many magic keys, the cumulative probability of failing one of the keys' generation is going up and this is causing random failures in the testsuite. > Moreover, the equality of magic keys is based only on the hashCode - with many keys, there is a non-trivial chance that the hashcodes will make two logically different keys equal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6868) Expose extra configuration for the SSLContext protocol in the Hot Rod client

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6868?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6868: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1357823|https://bugzilla.redhat.com/show_bug.cgi?id=1357823] from ON_QA to VERIFIED > Expose extra configuration for the SSLContext protocol in the Hot Rod client > ---------------------------------------------------------------------------- > > Key: ISPN-6868 > URL: https://issues.jboss.org/browse/ISPN-6868 > Project: Infinispan > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha3 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha4, 9.0.0.Final > > > Currently in the HotRod client the {{SSLContext}} is created with the hardcoded "TLS" protocol, and this can only be overriden by providing a whole custom instance of {{SSLContext}} programmatically. We should provide an extra property to change the protocol for the default SSLContext case, allowing it to be supported via properties files -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6497) SSL cert password has to be same as keystore password

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6497?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6497: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from ON_QA to VERIFIED > SSL cert password has to be same as keystore password > ----------------------------------------------------- > > Key: ISPN-6497 > URL: https://issues.jboss.org/browse/ISPN-6497 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Keystore password can be different from certificate private key password stored in the keystore. Currently, when setting up SSL for client - server communication, only keystore password can be configured and thus if keystore has different password than certificate private key, initialization of the keystore fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6482) Allow to HR client to specify only trustore

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6482?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6482: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from ON_QA to VERIFIED > Allow to HR client to specify only trustore > ------------------------------------------- > > Key: ISPN-6482 > URL: https://issues.jboss.org/browse/ISPN-6482 > Project: Infinispan > Issue Type: Enhancement > Components: Security > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > HR encryption over SSL can be set up on without client certificate validation on server side (i.e. no client certificate is needed at all), but HR client doesn't provide any straightforward way hot to configure only trust store. The only way (little bit awkward) is to construct directly SSLConfig and set it up in HR client config. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6438) A Hot Rod client should be able to configure the same properties with hotrod-client.properties file as the programatic API supports

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6438?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6438: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from ON_QA to VERIFIED > A Hot Rod client should be able to configure the same properties with hotrod-client.properties file as the programatic API supports > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6438 > URL: https://issues.jboss.org/browse/ISPN-6438 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > If a HotRod client is initialized by a hotrod-client.properties file and the RemoteCacheManager() constructor it should be possible to all possible properties. > The properties for > - SSL > - FILE_STORE * > - TRUST_STORE * > are not available with this configuration -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6574: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1332924|https://bugzilla.redhat.com/show_bug.cgi?id=1332924] from ON_QA to VERIFIED > JCache CacheManger need to know about existing caches if remote (HotRod) is used > -------------------------------------------------------------------------------- > > Key: ISPN-6574 > URL: https://issues.jboss.org/browse/ISPN-6574 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API. > Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also. > Excerpt from API Doc: > ------------------------------------ > K,V> Cache<K,V> getCache(String cacheName, > Class<K> keyType, > Class<V> valueType) > Looks up a managed Cache given its name. > This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified. > Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method. > Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail. > Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null. > Parameters: > cacheName - the name of the managed Cache to acquire > keyType - the expected Class of the key > valueType - the expected Class of the value > Returns: > the Cache or null if it does exist or can't be pre-configured > Throws: > IllegalStateException - if the CacheManager is isClosed() > IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache. > SecurityException - when the operation could not be performed due to the current security settings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1947) Automate staging repository step in release script

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-1947?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-1947: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4507 > Automate staging repository step in release script > -------------------------------------------------- > > Key: ISPN-1947 > URL: https://issues.jboss.org/browse/ISPN-1947 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Sanne Grinovero > Assignee: Sebastian Łaskawiec > Priority: Critical > > The Nexus staging plugin can be used to control the staging repository from command line (including authenticating with your account as set in your settings file) > https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6563: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1332936|https://bugzilla.redhat.com/show_bug.cgi?id=1332936] from ON_QA to VERIFIED > If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6563 > URL: https://issues.jboss.org/browse/ISPN-6563 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults. > But it is expected that the hotrod-client.properties are used to configure the remote connection. > The code is like this: > { > import javax.cache.*; > ... > CachingProvider jcacheProvider = Caching.getCachingProvider(); > CacheManager cacheManager = jcacheProvider.getCacheManager(); > } > The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties. > Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4390: ---------------------------------- Fix Version/s: 9.0.0.Beta1 > CHMv8 leaks ThreadLocal > ----------------------- > > Key: ISPN-4390 > URL: https://issues.jboss.org/browse/ISPN-4390 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 9.0.0.Beta1, 9.0.0.Final, 8.2.5.Final > > > As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 August 2016