July 2016 - infinispan-issues - Jboss List Archives

[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 MODIFIED to ON_QA > 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)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6589) ProtobufIndexedFieldProvider may mistakenly report nested fields as unindexed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6589?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6589: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1333177|https://bugzilla.redhat.com/show_bug.cgi?id=1333177] from MODIFIED to ON_QA > ProtobufIndexedFieldProvider may mistakenly report nested fields as unindexed > ----------------------------------------------------------------------------- > > Key: ISPN-6589 > URL: https://issues.jboss.org/browse/ISPN-6589 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 8.0.0.Final, 9.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 8.2.2.Final > > > Nested indexed fields may sometimes be reported as unindexed even if the metadata says otherwise. This may cause a query to be run fully or partially unindexed leading to perf issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6043) TransactionTable should ignore view changes during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6043?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6043: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1310583|https://bugzilla.redhat.com/show_bug.cgi?id=1310583] from MODIFIED to ON_QA > TransactionTable should ignore view changes during shutdown > ----------------------------------------------------------- > > Key: ISPN-6043 > URL: https://issues.jboss.org/browse/ISPN-6043 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Beta1, 8.2.0.Final, 8.1.1.Final > > > During shutdown, {{TransactionTable}} unregisters itself as a view change listener, but it can still receive view change notifications after it stopped the executor service. When that happens, it causes a {{RejectedExecutionException}} that is eventually logged by JGroups: > {noformat} > pbcast.GMS - JGRP000027: failed passing message up > java.lang.RuntimeException: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.util.concurrent.RejectedExecutionException] while invoking method [public void org.infinispan.transaction.TransactionTable.onViewChange(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.transaction.TransactionTable@3d5ab0ba > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:682) > at org.jgroups.JChannel.up(JChannel.java:733) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029) > at org.jgroups.protocols.RSVP.up(RSVP.java:201) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732) > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:922) > at org.jgroups.stack.Protocol.up(Protocol.java:412) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474) > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982) > at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912) > at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:255) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:288) > at org.jgroups.protocols.Discovery.up(Discovery.java:291) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1572) > at org.jgroups.protocols.TP$MyHandler.run(TP.java:1791) > 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:722) > Caused by: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.util.concurrent.RejectedExecutionException] while invoking method [public void org.infinispan.transaction.TransactionTable.onViewChange(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.transaction.TransactionTable@3d5ab0ba > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:287) > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:305) > at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.notifyViewChange(CacheManagerNotifierImpl.java:88) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport$NotifyViewChange.emitNotification(JGroupsTransport.java:638) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:708) > at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:602) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:679) > ... 25 more > Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1f5986a3 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2e964769[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1696] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:546) > at java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:646) > at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:641) > at org.infinispan.transaction.TransactionTable.onViewChange(TransactionTable.java:491) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:282) > ... 32 more > {noformat} > The exception is harmless for the stopping cache, the problem is that the following view change listeners are also skipped. We should fix both {{TransactionTable}} to avoid throwing the exception, and {{CacheManagerNotifier}} to ignore any exceptions during view changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 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 MODIFIED to ON_QA > 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)

8 years, 5 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 MODIFIED to ON_QA > 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)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5370) Make clear() non-transactional and lock free

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5370?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5370: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1303483|https://bugzilla.redhat.com/show_bug.cgi?id=1303483] from MODIFIED to ON_QA > Make clear() non-transactional and lock free > -------------------------------------------- > > Key: ISPN-5370 > URL: https://issues.jboss.org/browse/ISPN-5370 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.2.0.CR1, 7.2.0.Final > > > New semantic for clear: > * assumes no concurrent operation while the command is in progress > * Lock free (avoids any issues with stop-the-word or deadlocks) > * non-transactional (it does not interact with current running or others transactions) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 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 MODIFIED to ON_QA > 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)

8 years, 5 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 MODIFIED to ON_QA > 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)

8 years, 5 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 MODIFIED to ON_QA > 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)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6125: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1300133|https://bugzilla.redhat.com/show_bug.cgi?id=1300133] from MODIFIED to ON_QA > JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans > ---------------------------------------------------------------------------------- > > Key: ISPN-6125 > URL: https://issues.jboss.org/browse/ISPN-6125 > Project: Infinispan > Issue Type: Bug > Components: Core, Eviction > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Martin Gencur > Fix For: 8.2.0.Beta2, 8.1.2.Final > > > Description of problem: > Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX. > How reproducible: > Always. > Actual results: > evictions is always 0. > Expected results: > evictions should be the count of evicted entries. > Additional info: > This issue found in both of server and library modes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2016