September 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7041) Cloud cache store fails to create new container in OpenStack Swift

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-7041: ------------------------------------- Summary: Cloud cache store fails to create new container in OpenStack Swift Key: ISPN-7041 URL: https://issues.jboss.org/browse/ISPN-7041 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 8.2.4.Final Reporter: Vojtech Juranek Assignee: Vojtech Juranek When target container doesn't exists, cloud cache store will create it. However, on OpenStack Swift it fails with {noformat} Exception in thread "main" org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547) at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238) at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:890) at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636) at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438) at org.infinispan.demo.SwiftCacheStore.main(SwiftCacheStore.java:20) Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:171) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) ... 11 more Caused by: java.lang.IllegalArgumentException: location must be null or {scope=REGION, id=regionOne, description=regionOne, parent=openstack-swift} at com.google.common.base.Preconditions.checkArgument(Preconditions.java:148) at org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.createContainerInLocation(RegionScopedSwiftBlobStore.java:147) at org.jclouds.openstack.swift.v1.blobstore.RegionScopedSwiftBlobStore.createContainerInLocation(RegionScopedSwiftBlobStore.java:142) at org.infinispan.persistence.cloud.CloudStore.start(CloudStore.java:118) at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:138) ... 16 more {noformat} As jclouds doesn't require region to be defined for Swift, probably best approach is to allow users not to specify the region. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7036) Resolve classes properly when EmbeddedContextClassResolver is initialized with null

by Thomas Segismont (JIRA)

[ https://issues.jboss.org/browse/ISPN-7036?page=com.atlassian.jira.plugin.... ] Thomas Segismont commented on ISPN-7036: ---------------------------------------- [~dan.berindei] I think that when the TCCL is null, yes, we should assume application classes are in the same classloader as the ISPN classes. It is in the contract of Thread#getContextClassloader to [possibly return null|https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#getC...] > Resolve classes properly when EmbeddedContextClassResolver is initialized with null > ----------------------------------------------------------------------------------- > > Key: ISPN-7036 > URL: https://issues.jboss.org/browse/ISPN-7036 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > > Some applications set the main thread context classloader to null. This breaks the ISPN class resolver chain (EmbeddedContextClassResolver initialized with null classloader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3702: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1378875 Bugzilla Update: Perform > Too many threads for cleaning up infinispan transactions > -------------------------------------------------------- > > Key: ISPN-3702 > URL: https://issues.jboss.org/browse/ISPN-3702 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 5.3.0.Final > Environment: Mac and Linux > Reporter: Prasanth Pallamreddy > Assignee: Pedro Ruivo > Fix For: 9.0.0.Alpha2, 8.2.2.Final > > > When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following. > "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000] > "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000] > "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000] > "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000] > ... > Looking at the source code for > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > if (!totalOrder) { > // Periodically run a task to cleanup the transaction table from completed transactions. > ThreadFactory tf = new ThreadFactory() { > @Override > public Thread newThread(Runnable r) { > String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local"; > Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address); > th.setDaemon(true); > return th; > } > }; > executorService = Executors.newSingleThreadScheduledExecutor(tf); > This code can benefit from drawing the threads from a dedicated pool which is bounded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6041: ------------------------------------ [~galderz] it doesn't seem that different to me... The cause might be different, but they both result in a {{TransportException}} from {{TcpTransport.readByte}}, and are handled the same way in {{ClientListenerNotifier$EventDispatcher.run}}. And {{IOException: Connection reset by peer}} signals that the other end closed the socket, just like {{read()}} returning {{-1}}, so I think they *should* be handled the same way. > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Beta1 > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7036) Resolve classes properly when EmbeddedContextClassResolver is initialized with null

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7036?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7036: ------------------------------------------- Right... I completely forgot about it... [~tsegismont] Have you tried that? I think [~dan.berindei] has a point here... > Resolve classes properly when EmbeddedContextClassResolver is initialized with null > ----------------------------------------------------------------------------------- > > Key: ISPN-7036 > URL: https://issues.jboss.org/browse/ISPN-7036 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > > Some applications set the main thread context classloader to null. This breaks the ISPN class resolver chain (EmbeddedContextClassResolver initialized with null classloader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7036) Resolve classes properly when EmbeddedContextClassResolver is initialized with null

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7036?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-7036: ------------------------------------ What does it mean to resolve classes "properly" when we don't have a class loader? Should we just assume that all application classes are in the same classloader as the Infinispan classes? IMO it's the application's job to set up {{GlobalConfigurationBuilder}} with a classloader, either implicitly via the thread context classloader, or explicitly via {{GlobalConfigurationBuilder.classLoader(classLoader)}}. > Resolve classes properly when EmbeddedContextClassResolver is initialized with null > ----------------------------------------------------------------------------------- > > Key: ISPN-7036 > URL: https://issues.jboss.org/browse/ISPN-7036 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > > Some applications set the main thread context classloader to null. This breaks the ISPN class resolver chain (EmbeddedContextClassResolver initialized with null classloader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6970) Upgrade to JGroups 4.0.0.Alpha1

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-6970?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on ISPN-6970 at 9/23/16 7:49 AM: --------------------------------------------------------- When upgrading to Beta1, take a note of the following substitutions: * {{UUID.get()}} --> {{NameCache.get()}} * {{UUID.add()}} --> {{NameCache.add()}} was (Author: belaban): When upgrading to Beta1, take a note of the following substitutions: * {{UUID.get()}} --> {{NameCache.get()}} * {UUID.add()}} --> {{NameCache.add()}} > Upgrade to JGroups 4.0.0.Alpha1 > ------------------------------- > > Key: ISPN-6970 > URL: https://issues.jboss.org/browse/ISPN-6970 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > This will allow us to experiment with the changes in the JGroups 4.0 before it's set in stone. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6970) Upgrade to JGroups 4.0.0.Alpha1

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-6970?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-6970: -------------------------------- When upgrading to Beta1, take a note of the following substitutions: * {{UUID.get()}} --> {{NameCache.get()}} * {UUID.add()}} --> {{NameCache.add()}} > Upgrade to JGroups 4.0.0.Alpha1 > ------------------------------- > > Key: ISPN-6970 > URL: https://issues.jboss.org/browse/ISPN-6970 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > This will allow us to experiment with the changes in the JGroups 4.0 before it's set in stone. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7040) CacheEntryRemoved events seems not be be called when removing entry from Cache

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-7040: ----------------------------------------- Summary: CacheEntryRemoved events seems not be be called when removing entry from Cache Key: ISPN-7040 URL: https://issues.jboss.org/browse/ISPN-7040 Project: Infinispan Issue Type: Bug Reporter: Sebastian Łaskawiec Priority: Critical When working on Spring Cache integration I noticed that {{CacheEntryRemoved}} are not invoked when calling {{cache.remove}}. I'm not sure if this is not a bug. A funny thing is that they are called when closing the {{RemoteCacheManager}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7039) Fix CDI Documentation (add information about the split)

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-7039: ----------------------------------------- Summary: Fix CDI Documentation (add information about the split) Key: ISPN-7039 URL: https://issues.jboss.org/browse/ISPN-7039 Project: Infinispan Issue Type: Bug Affects Versions: 8.2.4.Final Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec The documentation mentions {{infinispan-cdi}} but we already did the split to {{infinispan-cdi-remote}} and {{infinispan-cdi-embedded}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2016