[JBoss JIRA] (ISPN-10248) Allow users to customize NearCache behavior
by Paul Ferraro (Jira)
Paul Ferraro created ISPN-10248:
-----------------------------------
Summary: Allow users to customize NearCache behavior
Key: ISPN-10248
URL: https://issues.jboss.org/browse/ISPN-10248
Project: Infinispan
Issue Type: Enhancement
Components: Hot Rod
Affects Versions: 9.4.14.Final, 10.0.0.Beta3
Reporter: Paul Ferraro
Assignee: Paul Ferraro
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)
6 years, 10 months
[JBoss JIRA] (ISPN-10247) tck-runner module discards server console output
by Dan Berindei (Jira)
Dan Berindei created ISPN-10247:
-----------------------------------
Summary: tck-runner module discards server console output
Key: ISPN-10247
URL: https://issues.jboss.org/browse/ISPN-10247
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Server
Affects Versions: 9.4.14.Final, 10.0.0.Beta3
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta4
Sometimes the server is unable to write to server.log, so the build should also keep the server console output.
Currently the console output is ignored, because {{infinispan-server.xml}} uses {{<exec spawn="true"}} and doesn't redirect the output to a file.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10247) tck-runner module discards server console output
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10247?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10247:
--------------------------------
Status: Open (was: New)
> tck-runner module discards server console output
> ------------------------------------------------
>
> Key: ISPN-10247
> URL: https://issues.jboss.org/browse/ISPN-10247
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 10.0.0.Beta3, 9.4.14.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> Sometimes the server is unable to write to server.log, so the build should also keep the server console output.
> Currently the console output is ignored, because {{infinispan-server.xml}} uses {{<exec spawn="true"}} and doesn't redirect the output to a file.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-6448) ClassNotFoundException warnings in infinispan-rhq-plugin and infinispan-jcache-tck-runner build
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-6448?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-6448.
--------------------------------
Fix Version/s: 9.0.0.Final
(was: 10.0.0.Final)
Resolution: Out of Date
RHQ plugin was removed with ISPN-6450
> ClassNotFoundException warnings in infinispan-rhq-plugin and infinispan-jcache-tck-runner build
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-6448
> URL: https://issues.jboss.org/browse/ISPN-6448
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 9.0.0.Final
>
>
> There are about 90 exceptions like this in total:
> {noformat}
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] 6550 [WARN] ClassFinder: From jar path org/infinispan/objectfilter/impl/ProtobufMatcher$1.class could not load class org.infinispan.objectfilter.impl.ProtobufMatcher$1
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] java.lang.ClassNotFoundException: org.infinispan.objectfilter.impl.ProtobufMatcher$1
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.lang.Class.forName0(Native Method) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at org.infinispan.commons.util.Util.loadClassStrict(Util.java:171) ~[infinispan-commons.jar:9.0.0-SNAPSHOT]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at org.infinispan.commons.util.ClassFinder.findClassesOnPath(ClassFinder.java:145) [infinispan-commons.jar:9.0.0-SNAPSHOT]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at org.infinispan.commons.util.ClassFinder.infinispanClasses(ClassFinder.java:90) [infinispan-commons.jar:9.0.0-SNAPSHOT]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.getMBeanClasses(RhqPluginXmlGenerator.java:117) [infinispan-tools.jar:9.0.0-SNAPSHOT]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.start(RhqPluginXmlGenerator.java:75) [infinispan-tools.jar:9.0.0-SNAPSHOT]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_45]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.Start.begin(Start.java:219) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.Start.begin(Start.java:205) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.Main.execute(Main.java:64) [tools.jar:?]
> [13:09:19] : [org.infinispan:infinispan-jcache-tck-runner] at com.sun.tools.javadoc.Main.main(Main.java:54) [tools.jar:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9716) Update internal remote listener code to support non blocking
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9716?page=com.atlassian.jira.plugin.... ]
Will Burns updated ISPN-9716:
-----------------------------
Fix Version/s: 10.0.0.Beta4
> Update internal remote listener code to support non blocking
> ------------------------------------------------------------
>
> Key: ISPN-9716
> URL: https://issues.jboss.org/browse/ISPN-9716
> Project: Infinispan
> Issue Type: Sub-task
> Components: Listeners
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> With ISPN-9714 we will not be able to have non blocking listeners. We need to update all of our remote listeners to use non blocking properly.
> Note that the client listeners themselves currently do not send a response, so this does not mean to update our client listener objects, but rather the code supporting them (ie. ClientListenerRegistry).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9722) Perform all CacheStore operations on a separate thread
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin.... ]
Will Burns commented on ISPN-9722:
----------------------------------
The big thing to watch out for with CallerRunsPolicy is we don't accidentally run operations on the wrong thread is more important, such as running a blocking operation on the CPU thread or CPU operation on the blocking thread pool (although the latter every once in a while wouldn't be that bad).
> Perform all CacheStore operations on a separate thread
> ------------------------------------------------------
>
> Key: ISPN-9722
> URL: https://issues.jboss.org/browse/ISPN-9722
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4, 10.0.0.Final
>
>
> Persistence is one of the few remaining systems that are not non blocking. This needs to be remedied. We will eventually need to add an SPI that does this, but for now we need to offload the persistence operations to a different thread pool.
> This should only require changes in the PersistenceManager to return non blocking methods (ie. return CompletionStage). We should then update references to use non blocking when possible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-9722) Perform all CacheStore operations on a separate thread
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin.... ]
Will Burns commented on ISPN-9722:
----------------------------------
{quote}
At some point we'll run out of memory and we'll stall waiting for the GC, so I still don't think we can guarantee we'll never block unless we have some other backpressure mechanism that prevents new cache invocations from running on the CPU thread pool even when the CPU thread pool is free.
{quote}
We actually have this already today, since we offload the server requests to a different thread pool. In this case it is based on how large of a queue we have configured. It appears that we enqueue everything in HR https://github.com/infinispan/infinispan/blob/master/server/core/src/main...
But I should clarify I meant to say under normal operation we should never have to worry about caller runs policy. The queue should be quite large to prevent having to run in caller runs policy, but not too large to cause OOM. Originally we had some of the queue sizes as 100K elements, which seems reasonable to me for a blocking thread pool queue. But this can be discussed as needed. One thing to note is the hope is that we would have just a CPU thread pool, blocking op thread pool and scheduled thread pool. So there would only need to be 3 queues which would help in sizing those properly as well. Then we can also use `LimitedExecutor` on top of these to guarantee FIFO or limit thread usage for given tasks as needed (which also has its own individual queues).
{quote}
Sorry I wasn't clear, I meant stores with write-behind enabled, which are wrapped in an AsyncCacheWriter. I understand that you would like the caller to never block, but I don't think we can guarantee that with the current SPI and without implementing backpressure first.
{quote}
This is a stop gap until the SPI is changed, I agree, in which case we shouldn't need to use a thread, but this is a simple step to getting to where we need to be. In regards to backpressure, we have CallerRunsPolicy as you mentioned and should be sufficient for the cases when we are absolutely swamped by a ton of async calls.
> Perform all CacheStore operations on a separate thread
> ------------------------------------------------------
>
> Key: ISPN-9722
> URL: https://issues.jboss.org/browse/ISPN-9722
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4, 10.0.0.Final
>
>
> Persistence is one of the few remaining systems that are not non blocking. This needs to be remedied. We will eventually need to add an SPI that does this, but for now we need to offload the persistence operations to a different thread pool.
> This should only require changes in the PersistenceManager to return non blocking methods (ie. return CompletionStage). We should then update references to use non blocking when possible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10220) Create named lambdas to identify which test is running
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10220?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10220:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6950
> Create named lambdas to identify which test is running
> ------------------------------------------------------
>
> Key: ISPN-10220
> URL: https://issues.jboss.org/browse/ISPN-10220
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Critical
> Fix For: 10.0.0.Beta4
>
>
> After ISPN-10148, all lambdas in the index will be the same. It will return only one test in the XML.
> For example:
> {code:java}
> // Put
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Functional Command
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Put all
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Put Async
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Compute
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> {code}
> will be reported only once like:
> {code:java}
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([$$Lambda$, false])
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10220) Create named lambdas to identify which test is running
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10220?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10220:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.0.0.Beta4
Resolution: Done
> Create named lambdas to identify which test is running
> ------------------------------------------------------
>
> Key: ISPN-10220
> URL: https://issues.jboss.org/browse/ISPN-10220
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Critical
> Fix For: 10.0.0.Beta4
>
>
> After ISPN-10148, all lambdas in the index will be the same. It will return only one test in the XML.
> For example:
> {code:java}
> // Put
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Functional Command
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Put all
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Put Async
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> // Compute
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([org.infinispan.api.APINonTxTest$$Lambda$1688/0x0000000100b08440@79ef4571, false])
> {code}
> will be reported only once like:
> {code:java}
> org.infinispan.api.APINonTxTest#testLockedStreamActuallyLocks([$$Lambda$, false])
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months