October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10822) java.lang.Error: Maximum permit count exceeded

by AshokKumar NV (Jira)

[ https://issues.jboss.org/browse/ISPN-10822?page=com.atlassian.jira.plugin... ] AshokKumar NV commented on ISPN-10822: -------------------------------------- Hi [~william.burns], Thanks for your valuable feedback, We are using infinispan in embedded mode, Currently we don't have any plan to migrate infinispan to latest version, Because we have updated recently. Do you have any reference tickets where similar issue is identified and fixed? I see we are getting an issues with infinispan with MS-SQL.? Regards, [~ashoktronix27] > java.lang.Error: Maximum permit count exceeded > ---------------------------------------------- > > Key: ISPN-10822 > URL: https://issues.jboss.org/browse/ISPN-10822 > Project: Infinispan > Issue Type: Bug > Components: Clustered Executor > Affects Versions: 9.4.4.Final > Reporter: AshokKumar NV > Assignee: Will Burns > Priority: Major > > We use an MS-SQL database when we are try to retrieve the data concurrently we are facing this issue. > Please find the stack trace. > {noformat} > java.lang.Error: Maximum permit count exceeded > at java.base/java.util.concurrent.Semaphore$Sync.tryReleaseShared(Semaphore.java:198) > at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1382) > at java.base/java.util.concurrent.Semaphore.release(Semaphore.java:432) > at io.reactivex.internal.operators.flowable.FlowableUsing$UsingSubscriber.onComplete(FlowableUsing.java:139) > at io.reactivex.internal.operators.flowable.FlowableUsing$UsingSubscriber.onComplete(FlowableUsing.java:148) > at io.reactivex.internal.subscriptions.EmptySubscription.complete(EmptySubscription.java:68) > at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribe(FlowableFromIterable.java:61) > at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribeActual(FlowableFromIterable.java:47) > at io.reactivex.Flowable.subscribe(Flowable.java:14409) > at io.reactivex.Flowable.subscribe(Flowable.java:14356) > at io.reactivex.internal.operators.flowable.FlowableUsing.subscribeActual(FlowableUsing.java:74) > at io.reactivex.Flowable.subscribe(Flowable.java:14409) > at io.reactivex.Flowable.subscribe(Flowable.java:14356) > at io.reactivex.internal.operators.flowable.FlowableUsing.subscribeActual(FlowableUsing.java:74) > at io.reactivex.Flowable.subscribe(Flowable.java:14409) > at io.reactivex.internal.operators.flowable.FlowableMap.subscribeActual(FlowableMap.java:38) > at io.reactivex.Flowable.subscribe(Flowable.java:14409) > at io.reactivex.internal.operators.flowable.BlockingFlowableIterable.iterator(BlockingFlowableIterable.java:42) > at org.infinispan.util.Closeables.iterator(Closeables.java:30) > at org.infinispan.stream.impl.local.PersistenceEntryStreamSupplier.lambda$null$5(PersistenceEntryStreamSupplier.java:104) > at org.infinispan.util.LazyConcatIterator.hasNext(LazyConcatIterator.java:43) > at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1811) > at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294) > at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206) > at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:169) > at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300) > at java.base/java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10871) Add org.aesh:readline to dependency management

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10871?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10871: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.1.0.Beta1 Resolution: Done > Add org.aesh:readline to dependency management > ---------------------------------------------- > > Key: ISPN-10871 > URL: https://issues.jboss.org/browse/ISPN-10871 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.1.0.Beta1 > > > Add the {{org.aesh:readline}} to the dependency management so its version can be overwritten downstream. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10872) Update rxjava2 to 2.2.12

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10872?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10872: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update rxjava2 to 2.2.12 > ------------------------ > > Key: ISPN-10872 > URL: https://issues.jboss.org/browse/ISPN-10872 > Project: Infinispan > Issue Type: Task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.1.0.Beta1 > > > We should update rxjava2 dependency to a more up to date version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8319) Restore mechanism to manipulate Weigher implementation used by Caffeine

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-8319?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-8319: ---------------------------------- Assignee: Will Burns > Restore mechanism to manipulate Weigher implementation used by Caffeine > ----------------------------------------------------------------------- > > Key: ISPN-8319 > URL: https://issues.jboss.org/browse/ISPN-8319 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction > Affects Versions: 9.1.0.Final > Reporter: Paul Ferraro > Assignee: Will Burns > Priority: Major > > Infinispan 9.1 allows a user to manipulate the Weigher implementation used by Caffeine to by configuring a cache with a custom DataContainer that uses a specific EntrySizeCalculator implementation. However, the DataContainerConfiguration object is deprecated, suggesting that a future release will no longer expose a mechanism for doing this. Such a mechanism is necessary to allow users to exempt specific cache entries (while allowing others) from eviction. > One proposal is to allow users to specify an EntrySizeCalculator via the MemoryConfigurationBuilder. > e.g. > {code:java} > public interface EntrySizeCalculatorProvider { > <K, V> EntrySizeCalculator<K, V> getEntrySizeCalculator(); > } > {code} > MemoryConfigurationBuilder.java: > {code:java} > public MemoryConfigurationBuilder.entrySizeCalculatorProvider(EntrySizeCalculatorProvider provider) { > // ... > } > {code} > Additionally, we can reinterpret EvictionType as a specific EntrySizeCalculatorProvider implementation. > e.g. MemoryConfigurationBuilder.java: > {code:java} > private static final Map<EvictionType, EntrySizeCalculatorProvider> PROVIDERS = new EnumMap<>(EvictionType.class); > static { > PROVIDERS.put(EvictionType.COUNT, new EntrySizeCalculatorProvider() { > public <K, V> EntrySizeCalculator<K, V> getEntrySizeCalculator() { > return (key, value) -> 1L; > } > }); > PROVIDERS.put(EvictionType.MEMORY, new EntrySizeCalculatorProvider() { > public <K, V> EntrySizeCalculator<K, V> getEntrySizeCalculator() { > return new WrappedByteArraySizeCalculator<>(new PrimitiveEntrySizeCalculator()); > } > }); > } > MemoryConfigurationBuilder evictionType(EvictionType type) { > this.entrySizeCalculatorProvider(PROVIDERS.get(type)); > return this; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10868) Default whitelist should allow primitives and arrays

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10868?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10868: -------------------------------- Fix Version/s: 10.1.0.Final (was: 10.0.1.Final) > Default whitelist should allow primitives and arrays > ---------------------------------------------------- > > Key: ISPN-10868 > URL: https://issues.jboss.org/browse/ISPN-10868 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.4.16.Final, 10.0.0.Final > Reporter: Dan Berindei > Priority: Major > Fix For: 10.1.0.Final > > > Java serialization whitelist should include primitive wrapper classes and arrays types, if only because it's tedious to specify all of them in the configuration. > There's a similar argument for adding {{java.util.ArrayList}} to the default whitelist, especially to use as keys, because {{Object[]}} keys do not work with {{OBJECT}} storage ({{equals()}} and {{hashCode()}} are wrong). I'm not convinced yet, because applications eventually want to use a custom key class, and POCs can get away with converting to {{String}} and concatenating. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10730) Support INADDR_ANY in Hot Rod

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10730?page=com.atlassian.jira.plugin... ] Tristan Tarrant commented on ISPN-10730: ---------------------------------------- My plan is to build a table of all interfaces and their prefix and then match the incoming socket to the prefix. > Support INADDR_ANY in Hot Rod > ----------------------------- > > Key: ISPN-10730 > URL: https://issues.jboss.org/browse/ISPN-10730 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.0.CR3 > Reporter: Diego Lovison > Assignee: Tristan Tarrant > Priority: Major > > When working with WF ( Default ISPN Server when running the version 9.4), we can expose the server ports with the current machine's IP address using {{-b 0.0.0.0}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10875) SecureCacheImpl should not require ADMIN permission

by Dan Berindei (Jira)

Dan Berindei created ISPN-10875: ----------------------------------- Summary: SecureCacheImpl should not require ADMIN permission Key: ISPN-10875 URL: https://issues.jboss.org/browse/ISPN-10875 Project: Infinispan Issue Type: Bug Components: Core, Security Affects Versions: 10.0.0.Final Reporter: Dan Berindei Fix For: 10.1.0.Final {{DefaultCacheManager}} methods don't always require {{ADMIN}} permission, and if they require a certain permission they request it explicitly. {{SecureCacheImpl.getCacheManager()}} requiring {{ADMIN}} restricts access to methods like {{EmbeddedCacheManager.getAddress()}} unnecessarily, and forces us to do things like cache the cache manager reference in a field or use a separate security action just to get the cache manager. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10874) Binding to 0.0.0.0 causes Hot Rod clients connection errors

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-10874: ---------------------------------------- Summary: Binding to 0.0.0.0 causes Hot Rod clients connection errors Key: ISPN-10874 URL: https://issues.jboss.org/browse/ISPN-10874 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 10.0.0.Final Reporter: Gustavo Fernandes I am starting the server with server.sh -Dinfinispan.bind.address=0.0.0.0 but when connecting through Hot Rod, it throws a weird error: {noformat} org.infinispan.client.hotrod.exceptions.TransportException:: io.netty.channel.AbstractChannel$AnnotatedConnectException: syscall:getsockopt(..) failed: Connection refused: /0.0.0.0:11222 at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:79) at org.infinispan.client.hotrod.impl.Util.await(Util.java:52) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:542) {noformat} I'd expect 0.0.0.0 to mean a "bind to all interfaces" ? In any case, this 0.0.0.0 seems to be passed down to the HR client and it doesn't know what to do with it... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10867) AsyncStoreWithoutEvictionFunctionalTestsegmented creates data directories in core directory

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10867?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10867. --------------------------------- Resolution: Done > AsyncStoreWithoutEvictionFunctionalTestsegmented creates data directories in core directory > ------------------------------------------------------------------------------------------- > > Key: ISPN-10867 > URL: https://issues.jboss.org/browse/ISPN-10867 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.1.Final, 10.1.0.Beta1 > > > Now that stores are segmented by default some tests were creating data directories in the wrong locations causing lots of unneeded and uncleaned directories after a test run. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10873) Add features toggle in the console

by Katia Aresti (Jira)

Katia Aresti created ISPN-10873: ----------------------------------- Summary: Add features toggle in the console Key: ISPN-10873 URL: https://issues.jboss.org/browse/ISPN-10873 Project: Infinispan Issue Type: Feature Request Components: Console Reporter: Katia Aresti feature toggle to add and remove features -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2019