[JBoss JIRA] (ISPN-1441) Better and more sensible executor configuration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1441?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-1441.
------------------------------------
Resolution: Won't Fix
> Better and more sensible executor configuration
> -----------------------------------------------
>
> Key: ISPN-1441
> URL: https://issues.jboss.org/browse/ISPN-1441
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: executors
>
> Dan and I had a chat about ISPN-1396 and we both agreed that a better configuration and management approach is needed for Infinispan's executors:
> - Firstly, out of the box for SE environments, Infinispan should have executors configured with newCachedThreadPool because they provide better queuing performance than a fixed thread pool.
> - Sure, in an managed env (i.e. AS), this won't fly, which is why all executors need to be injectable. This should be in place once ISPN-1396 is in place.
> - So, if we go for cached thread pools for SE environments, we don't need any of the properties of executors any more. Besides, these can be more confusing for the user (there is knowledged of at least one case where things went wrong due to bad config here). So, the configuration would be limited to injecting executors. If you need any specific executor settings, pass us the right executors. To aid these cases, we could have some executor builders available with some common executor configuration for managed envs (i.e. we could borrow settings from AS?)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-1935) Provide tree cache specific listener callbacks
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1935?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-1935.
------------------------------------
Resolution: Won't Fix
> Provide tree cache specific listener callbacks
> ----------------------------------------------
>
> Key: ISPN-1935
> URL: https://issues.jboss.org/browse/ISPN-1935
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 5.1.2.FINAL
> Reporter: Michael Gronau
> Assignee: Galder Zamarreño
> Labels: API, CacheEntryModified, Notifications, TreeCache
> Attachments: TreeListenerTest.java
>
>
> A put operation to the TreeCache API causes multiple CacheEntryModified events to be fired. The data map (an AtomicHashMap) is always empty and does not contain the modifications. The notifications are fired twice for isPre=false and isPre=true, which means they are fired 4 times.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-2280) Async cache store shutdown timeout default value should be -1
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2280?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-2280.
------------------------------------
Resolution: Out of Date
> Async cache store shutdown timeout default value should be -1
> -------------------------------------------------------------
>
> Key: ISPN-2280
> URL: https://issues.jboss.org/browse/ISPN-2280
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration, Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Minor
>
> We should strive for correctness really.
> Better to have someone complain about Infinispan not finishing rather than missing data in the cache store.
> To avoid confusion, we should wait for a bit of time, i.e. 1 minute, and then if the async store has not finished yet, log a WARN message indicating what's up, but then carry on waiting forever (or whatever the defined user time - minus the 60 seconds) by default.
> If the user defined timeout is less than 60 seconds, wait that long.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9305) NullPointerException in cache.size() after cache.containsKey()
by Dan Berindei (JIRA)
Dan Berindei created ISPN-9305:
----------------------------------
Summary: NullPointerException in cache.size() after cache.containsKey()
Key: ISPN-9305
URL: https://issues.jboss.org/browse/ISPN-9305
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.3.0.CR1
Reporter: Dan Berindei
Fix For: 9.3.0.Final
{{containsKey(missingKey)}} registers a {{NullCacheEntry}} in the transaction context to signal that the entry was already checked and it does not exist.
If the cache is repl/dist, {{size()}} uses distributed streams. {{TxDistributedCacheStream}} doesn't know about {{NullCacheEntry}} and tries to compute the segment of its key, causing a {{NullPointerException}}:
{noformat}
14:52:36,645 ERROR (testng-test) [InvocationContextInterceptor] ISPN000136: Error executing command SizeCommand, writing keys []
java.lang.NullPointerException: null
at org.infinispan.commons.hash.MurmurHash3.hash(MurmurHash3.java:399) ~[classes/:?]
at org.infinispan.distribution.ch.impl.HashFunctionPartitioner.getSegment(HashFunctionPartitioner.java:45) ~[classes/:?]
at org.infinispan.stream.impl.AbstractCacheStream.isPrimaryOwner(AbstractCacheStream.java:425) ~[classes/:?]
at org.infinispan.stream.impl.tx.TxDistributedCacheStream.lambda$null$0(TxDistributedCacheStream.java:68) ~[classes/:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) ~[?:1.8.0_171]
at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1625) ~[?:1.8.0_171]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_171]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_171]
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_171]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_171]
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_171]
at org.infinispan.stream.impl.tx.TxDistributedCacheStream.lambda$supplierForSegments$2(TxDistributedCacheStream.java:70) ~[classes/:?]
at org.infinispan.stream.impl.termop.SegmentRetryingOperation.performOperation(SegmentRetryingOperation.java:78) ~[classes/:?]
at org.infinispan.stream.impl.AbstractCacheStream.performOperationRehashAware(AbstractCacheStream.java:288) ~[classes/:?]
at org.infinispan.stream.impl.AbstractCacheStream.performOperation(AbstractCacheStream.java:232) ~[classes/:?]
at org.infinispan.stream.impl.DistributedCacheStream.count(DistributedCacheStream.java:426) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.perform(SizeCommand.java:45) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.perform(SizeCommand.java:20) ~[classes/:?]
at org.infinispan.interceptors.impl.CallInterceptor.visitCommand(CallInterceptor.java:29) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitSizeCommand(BaseDistributionInterceptor.java:122) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.impl.TxInterceptor.visitSizeCommand(TxInterceptor.java:270) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:41) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) ~[classes/:?]
at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:352) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123) ~[classes/:?]
at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90) ~[classes/:?]
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitSizeCommand(DDAsyncInterceptor.java:100) ~[classes/:?]
at org.infinispan.commands.read.SizeCommand.acceptVisitor(SizeCommand.java:35) ~[classes/:?]
at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50) ~[classes/:?]
at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248) ~[classes/:?]
at org.infinispan.cache.impl.CacheImpl.size(CacheImpl.java:443) ~[classes/:?]
at org.infinispan.cache.impl.CacheImpl.size(CacheImpl.java:438) ~[classes/:?]
at org.infinispan.cache.impl.AbstractDelegatingCache.size(AbstractDelegatingCache.java:313) ~[classes/:?]
{noformat}
{{CacheAPIOptimisticTest.testSizeInExplicitTxWithNonExistent}} tests this scenario, but only with a local cache.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-2819) REST server ignores client header Accept-Charset
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2819?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2819:
----------------------------------------
[~gustavonalle] Is this something we can resolve better now that we have mime type information and transcoding?
> REST server ignores client header Accept-Charset
> ------------------------------------------------
>
> Key: ISPN-2819
> URL: https://issues.jboss.org/browse/ISPN-2819
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 5.2.1.Final
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Minor
>
> In a HTTP GET request, the client can specify an {{Accept-Charset}} header. The REST server will ignore it, and it will always send the response with the original PUT/POST request's charset.
> I think the server should make an effort to transform the value data from the PUT charset to the GET charset. At the moment we don't even parse the PUT charset, we just store the {{Content-Type}} header.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-2841) DefaultExecutorService: No possibility to set ClassLoader used for cloning Callables
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2841?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-2841.
------------------------------------
Resolution: Out of Date
> DefaultExecutorService: No possibility to set ClassLoader used for cloning Callables
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2841
> URL: https://issues.jboss.org/browse/ISPN-2841
> Project: Infinispan
> Issue Type: Enhancement
> Components: Clustered Executor
> Affects Versions: 5.2.1.Final
> Reporter: Carsten Lohmann
> Assignee: Galder Zamarreño
>
> When using the DistributedExecutorService we noticed that the ContextClassLoader of the current thread is used for cloning the Callable.
> But this ClassLoader wasn't able to find the Callable class in our case, so we got this exception:
> {noformat}
> org.infinispan.CacheException: java.lang.ClassNotFoundException: [...]Callable
> at org.infinispan.util.Util.cloneWithMarshaller(Util.java:259)
> at org.infinispan.distexec.DefaultExecutorService.clone(DefaultExecutorService.java:555)
> at org.infinispan.distexec.DefaultExecutorService.submitEverywhere(DefaultExecutorService.java:510)
> at org.infinispan.distexec.DefaultExecutorService.submitEverywhere(DefaultExecutorService.java:497)
> [...]
> Caused by: java.lang.ClassNotFoundException: [...]Callable
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:893)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:163)
> at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:116)
> at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:106)
> at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:99)
> at org.infinispan.util.Util.cloneWithMarshaller(Util.java:254)
> {noformat}
> So there should be a possibility to explicitly set the ClassLoader that the ExecutorService will use for cloning the Callable.
> Maybe by using the ClassLoader set via AdvancedCache.with(ClassLoader) on the AdvancedCache given to the ExecutorService.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-2851) add log.info when using backported concurrent hash map
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2851?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-2851.
------------------------------------
Resolution: Out of Date
> add log.info when using backported concurrent hash map
> ------------------------------------------------------
>
> Key: ISPN-2851
> URL: https://issues.jboss.org/browse/ISPN-2851
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 5.2.2.Final
> Reporter: Mathieu Lachance
> Assignee: Galder Zamarreño
> Priority: Minor
>
> it would be nice if there was a bit more logging information when using backported concurrent hash map since it is activation is not only based on the :
> Boolean.getBoolean("infinispan.unsafe.allow_jdk8_chm");
> property as we could think.
> static {
> boolean sunIncompatibleJvm;
> boolean jdk8;
> boolean allowExperimentalMap = Boolean.getBoolean("infinispan.unsafe.allow_jdk8_chm");
> try {
> Class.forName("com.sun.unsafe.Unsafe");
> sunIncompatibleJvm = false;
> } catch (ClassNotFoundException e) {
> sunIncompatibleJvm = true;
> }
>
> try {
> Class.forName("java.util.concurrent.atomic.LongAdder");
> jdk8 = true;
> } catch (ClassNotFoundException e) {
> jdk8 = false;
> }
> if (jdk8 || sunIncompatibleJvm || !allowExperimentalMap){
> MAP_CREATOR = new JdkConcurrentMapCreator();
> }
> else{
> MAP_CREATOR = new BackportedV8ConcurrentMapCreator();
> logger.info("using backported jdk8 concurrent hash map implementation");
> }
> }
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months