July 2016 - infinispan-issues - Jboss List Archives

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

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6910: --------------------------------- Summary: 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 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6779) Improve Security Configuration screen

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6779?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-6779. -------------------------------- Resolution: Done > Improve Security Configuration screen > ------------------------------------- > > Key: ISPN-6779 > URL: https://issues.jboss.org/browse/ISPN-6779 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Beta2 > > > Infinispan administrators must be able to fully control authentication and authorization settings through the console. > - Improve cache container scurity > - Improve cache security -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1357823|https://bugzilla.redhat.com/show_bug.cgi?id=1357823] from POST to MODIFIED > 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, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1332936|https://bugzilla.redhat.com/show_bug.cgi?id=1332936] from POST to MODIFIED > 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, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1332924|https://bugzilla.redhat.com/show_bug.cgi?id=1332924] from POST to MODIFIED > 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, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from POST to MODIFIED > 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, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from POST to MODIFIED > 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, 4 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: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1339313|https://bugzilla.redhat.com/show_bug.cgi?id=1339313] from POST to MODIFIED > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3938) AdvancedAsyncCacheLoader.process() concurrency issues

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3938: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1312186|https://bugzilla.redhat.com/show_bug.cgi?id=1312186] from POST to MODIFIED > AdvancedAsyncCacheLoader.process() concurrency issues > ----------------------------------------------------- > > Key: ISPN-3938 > URL: https://issues.jboss.org/browse/ISPN-3938 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Sebastian Łaskawiec > Fix For: 8.2.0.CR1 > > > {{AdvancedAsyncCacheLoader.process()}} calls {{advancedLoader().process()}} to collect all the keys in the store, but the HashSet used to collect the keys it not thread-safe. This can cause problems, e.g. during state transfer: > {noformat} > WARN cheTopologyControlCommand | ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=sessions, type=CH_UPDATE, sender=alfie-lt-46127, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=60, numOwners=1, members=[alfie-lt-46127]}, pendingCH=null, throwable=null, viewId=1}java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926) > at java.util.HashMap$KeyIterator.next(HashMap.java:960) > at org.infinispan.persistence.async.AdvancedAsyncCacheLoader.process(AdvancedAsyncCacheLoader.java:80) > at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:414) > at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:910) > at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:393) > at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:178) > at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:38) > at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:100) > at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:191) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:152) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:124) > at org.infinispan.topology.ClusterTopologyManagerImpl$3.run(ClusterTopologyManagerImpl.java:606) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6276) Non-threadsafe use of HashSet in AdvancedAsyncCacheLoader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6276?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6276: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1312186|https://bugzilla.redhat.com/show_bug.cgi?id=1312186] from POST to MODIFIED > Non-threadsafe use of HashSet in AdvancedAsyncCacheLoader > ---------------------------------------------------------- > > Key: ISPN-6276 > URL: https://issues.jboss.org/browse/ISPN-6276 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Sebastian Łaskawiec > > org.infinispan.persistence.async.AdvancedAsyncCacheLoader$process creates a HashSet, and passes it to loadAllKeys(). > loadAllKeys() creates a task to get each key and add it to the HashSet. > This task is run by org.infinispan.persistence.file.SingleFileStore#process, which runs it in multiple threads at once (one thread per key). > There is no synchronization on that HashSet that is shared by the multiple threads. > HashSet is not thread safe. One known side effect of non-synchronized access by multiple threads is infinite loops, which has been witnessed here. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2016