[JBoss JIRA] (ISPN-10401) Counters summary over REST
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-10401?page=com.atlassian.jira.plugin... ]
Gustavo Fernandes updated ISPN-10401:
-------------------------------------
Description:
Provide an endpoint to obtain summary about all counters: possibly having config, name, and current value.
Also, possibility to filter counters by type (strong/weak)
was:Provide an endpoint to obtain summary about all counters: possibly having config, name, and current value.
> Counters summary over REST
> --------------------------
>
> Key: ISPN-10401
> URL: https://issues.jboss.org/browse/ISPN-10401
> Project: Infinispan
> Issue Type: Feature Request
> Components: REST
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> Provide an endpoint to obtain summary about all counters: possibly having config, name, and current value.
> Also, possibility to filter counters by type (strong/weak)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10401) Counters summary over REST
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-10401:
----------------------------------------
Summary: Counters summary over REST
Key: ISPN-10401
URL: https://issues.jboss.org/browse/ISPN-10401
Project: Infinispan
Issue Type: Feature Request
Components: REST
Reporter: Gustavo Fernandes
Provide an endpoint to obtain summary about all counters: possibly having config, name, and current value.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10398) Docs: Fix CLI Attribute
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10398?page=com.atlassian.jira.plugin... ]
Ryan Emerson resolved ISPN-10398.
---------------------------------
Fix Version/s: 10.0.0.Beta4
9.4.16.Final
Resolution: Done
> Docs: Fix CLI Attribute
> -----------------------
>
> Key: ISPN-10398
> URL: https://issues.jboss.org/browse/ISPN-10398
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation-Core
> Affects Versions: 10.0.0.Beta3, 9.4.15.Final
> Reporter: Donald Naro
> Assignee: Donald Naro
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.16.Final
>
>
> {brandcli} is not correct for community.
> Community {brandcli} resolves to ispn-cli
> Product {brandcli} resolves to cli.sh
> Need to update CLI examples that use this variable.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10257) Remove unused and declared dependencies (9.4 only)
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10257?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10257:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.16.Final
Resolution: Done
> Remove unused and declared dependencies (9.4 only)
> --------------------------------------------------
>
> Key: ISPN-10257
> URL: https://issues.jboss.org/browse/ISPN-10257
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 9.4.14.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 9.4.16.Final
>
>
> Unused dependencies found:
> {noformat}
> INFO: Dependencies to remove (total 16):
> kr.motd.maven:os-maven-plugin
> org.apache.ant:ant
> org.apache.ant:ant-launcher
> org.apache.maven.plugins:maven-help-plugin
> org.apache.maven.plugins:maven-scm-plugin
> org.beanshell:bsh
> org.codehaus.mojo:appassembler-maven-plugin
> org.codehaus.mojo:versions-maven-plugin
> org.eclipse.m2e:lifecycle-mapping
> org.glassfish.jaxb:jaxb-core
> org.jboss.sasl:jboss-sasl
> org.tukaani:xz
> org.wildfly:wildfly-dist
> org.wildfly.security:wildfly-security-manager
> xalan:serializer
> xalan:xalan
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10363) LazyInitializingExecutorService is not thread-safe
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10363?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10363:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.16.Final
Resolution: Done
> LazyInitializingExecutorService is not thread-safe
> --------------------------------------------------
>
> Key: ISPN-10363
> URL: https://issues.jboss.org/browse/ISPN-10363
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3, 9.4.15.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4, 9.4.16.Final
>
>
> {{LazyInitializingExecutorService.shutdown()}} is not synchronized, so it may miss the executor created on another thread.
> Normally the long time between the first use and stop is long enough for this to be a non-issue, but it does cause random thread leaks in {{PersistenceManagerTest}}:
> {noformat}
> 17:57:06,421 DEBUG (testng-PersistenceManagerTest:[]) [DefaultCacheManager] Started cache manager PersistenceManagerTest-NodeB on null
> 17:57:06,423 INFO (testng-PersistenceManagerTest:[]) [TestSuiteProgress] Test starting: org.infinispan.persistence.PersistenceManagerTest.testProcessAfterStop
> 17:57:06,446 INFO (testng-PersistenceManagerTest:[]) [TestSuiteProgress] Test succeeded: org.infinispan.persistence.PersistenceManagerTest.testProcessAfterStop
> 17:57:06,447 DEBUG (testng-PersistenceManagerTest:[]) [DefaultCacheManager] Stopped cache manager PersistenceManagerTest-NodeB
> 17:58:38,062 WARN (main:[]) [ThreadLeakChecker] Possible leaked thread:
> "async-thread-PersistenceManagerTest-NodeB-p54399-t1" daemon prio=5 tid=0x2ab4c nid=NA waiting
> java.lang.Thread.State: WAITING
> at java.base(a)11.0.3/jdk.internal.misc.Unsafe.park(Native Method)
> at java.base@11.0.3/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at java.base@11.0.3/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
> at java.base@11.0.3/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
> at java.base@11.0.3/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
> at java.base@11.0.3/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
> at java.base@11.0.3/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.3/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10070) DefaultCacheManager should stop components after start failure
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10070?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10070:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> DefaultCacheManager should stop components after start failure
> --------------------------------------------------------------
>
> Key: ISPN-10070
> URL: https://issues.jboss.org/browse/ISPN-10070
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.10.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.16.Final
>
>
> Currently it is impossible to release all the resources allocated during startup if the {{DefaultCacheManager}} instance was created with {{start=true}}. The user has to do something like this:
> {code:java}
> DefaultCacheManager manager = new DefaultCacheManager(..., false);
> try {
> manager.start();
> } catch (Throwable t) {
> manager.stop();
> throw t;
> }
> {code}
> Both the constructor and the public {{start()}} method should clean up the started components after a startup failure, so that the user doesn't have to call {{stop()}} explicitly.
> Our tests do not currently call {{stop()}} explicitly, so they leak threads and sockets when a manager fails to start (e.g. because something went wrong with the {{CONFIG}} cache).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (ISPN-10248) Allow users to customize NearCache behavior per RemoteCache
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10248?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10248:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.16.Final
Resolution: Done
> Allow users to customize NearCache behavior per RemoteCache
> -----------------------------------------------------------
>
> Key: ISPN-10248
> URL: https://issues.jboss.org/browse/ISPN-10248
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hot Rod
> Affects Versions: 10.0.0.Beta3, 9.4.14.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.16.Final
>
>
> I have the need to customize L1 configuration beyond the simple max-size capability. To do this, I can extend RemoteCacheManager and override the protected createNearCacheService(...) method. However, this method returns a NearCacheService implementation, instead of a NearCache. No matter, I can still extend NearCacheService and override the protected createNearCache(NearCacheConfiguration config) method. However, this method returns a NearCache interface which is package protected. Consequently, customizing near caching logic is impossible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months