[JBoss JIRA] (ISPN-6630) NotSerializableException while executing streams via JavaScript in a cluster in DIST mode (without additional casting to Serializable)
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6630?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6630:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> NotSerializableException while executing streams via JavaScript in a cluster in DIST mode (without additional casting to Serializable)
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6630
> URL: https://issues.jboss.org/browse/ISPN-6630
> Project: Infinispan
> Issue Type: Bug
> Components: Tasks
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha3, 9.0.0.Final
>
>
> When running map/reduce task using distributed streams through Javascript in DIST/REPL mode, then the following exception is thrown:
> {code}
> 15:02:43,476 ERROR (remote-thread-ClusteredScriptingTest-NodeF-p38-t6) [RpcManagerImpl] ISPN000073: Unexpected error while replicating
> org.infinispan.commons.marshall.NotSerializableException: org.infinispan.scripting.impl.DataTypedCache
> Caused by: an exception which occurred:
> in field capturedArgs
> in object org.infinispan.scripting.impl.DataTypedCache$$Lambda$97/1644130139@5a8a3b80
> -> toString = org.infinispan.scripting.impl.DataTypedCache$$Lambda$97/1644130139@5a8a3b80
> in object java.util.ArrayDeque@2c4c2ba3
> -> toString = [org.infinispan.stream.impl.intops.object.MapOperation@31f4ac20]
> in object org.infinispan.stream.impl.termop.SegmentRetryingOperation@1aad4974
> -> toString = org.infinispan.stream.impl.termop.SegmentRetryingOperation@1aad4974
> in object org.infinispan.stream.impl.StreamRequestCommand@734ebbb6
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredScriptingTest-NodeF-8182, see cause for remote stack trace
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1318)
> at org.infinispan.scripting.ClusteredScriptingTest.testDistributedMapReduceStreamWithFlag(ClusteredScriptingTest.java:127)
> 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:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:122)
> 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:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredScriptingTest-NodeF-8182, see cause for remote stack trace
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
> at org.infinispan.scripting.ClusteredScriptingTest$6.call(ClusteredScriptingTest.java:139)
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1314)
> ... 29 more
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredScriptingTest-NodeF-8182, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:818)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$306(JGroupsTransport.java:648)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:151)
> at org.jgroups.blocks.UnicastRequest.receiveResponse(UnicastRequest.java:70)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:369)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:233)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.marshall.NotSerializableException: org.infinispan.scripting.impl.DataTypedCache
> Caused by: an exception which occurred:
> in field capturedArgs
> in object org.infinispan.scripting.impl.DataTypedCache$$Lambda$97/1644130139@5a8a3b80
> -> toString = org.infinispan.scripting.impl.DataTypedCache$$Lambda$97/1644130139@5a8a3b80
> in object java.util.ArrayDeque@2c4c2ba3
> -> toString = [org.infinispan.stream.impl.intops.object.MapOperation@31f4ac20]
> in object org.infinispan.stream.impl.termop.SegmentRetryingOperation@1aad4974
> -> toString = org.infinispan.stream.impl.termop.SegmentRetryingOperation@1aad4974
> in object org.infinispan.stream.impl.StreamRequestCommand@734ebbb6
> -> toString = StreamRequestCommand{cacheName='___defaultcache'}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6706) Purging cache writers is [mostly] redundant when eviction is disabled and preload is enabled
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6706?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6706:
---------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4373
> Purging cache writers is [mostly] redundant when eviction is disabled and preload is enabled
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-6706
> URL: https://issues.jboss.org/browse/ISPN-6706
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 8.2.2.Final
> Reporter: Krzysztof Sobolewski
>
> This issue arised when I was testing a cluster with about 16 million entries. Our configuration is that all the data is also kept in memory, so eviction is disabled in this cache. But expiration is enabled. During the test I noticed pauses that started small but increased while the test was progressing, reaching more than 20 seconds at one point. After ruling out maintenance tasks in MySQL that could interfere, I discovered that the pause is caused by the expiration thread purging the database for expired entries. This was a huge and unnecessary drag so I hacked Infinispan to skip the purge of persistent state in cases when it's likely to be redundant with purging the transient state. I say "likely" because entries evicted maually via the evict() call poke a huge hole in the underlying assumptions :) Anyway, our cluster no longer regularly pauses for half a minute, so here's something for your consideration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6706) Purging cache writers is [mostly] redundant when eviction is disabled and preload is enabled
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-6706:
------------------------------------------
Summary: Purging cache writers is [mostly] redundant when eviction is disabled and preload is enabled
Key: ISPN-6706
URL: https://issues.jboss.org/browse/ISPN-6706
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 8.2.2.Final
Reporter: Krzysztof Sobolewski
This issue arised when I was testing a cluster with about 16 million entries. Our configuration is that all the data is also kept in memory, so eviction is disabled in this cache. But expiration is enabled. During the test I noticed pauses that started small but increased while the test was progressing, reaching more than 20 seconds at one point. After ruling out maintenance tasks in MySQL that could interfere, I discovered that the pause is caused by the expiration thread purging the database for expired entries. This was a huge and unnecessary drag so I hacked Infinispan to skip the purge of persistent state in cases when it's likely to be redundant with purging the transient state. I say "likely" because entries evicted maually via the evict() call poke a huge hole in the underlying assumptions :) Anyway, our cluster no longer regularly pauses for half a minute, so here's something for your consideration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6705) Container does not restart after clicking "restart now" in Thread Pools tab
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6705?page=com.atlassian.jira.plugin.... ]
Ryan Emerson moved JDG-395 to ISPN-6705:
----------------------------------------
Project: Infinispan (was: JBoss Data Grid)
Key: ISPN-6705 (was: JDG-395)
Workflow: GIT Pull Request with Triage workflow (was: CDW with loose statuses v1)
Component/s: Console
(was: Management and Monitoring)
Affects Version/s: 9.0.0.Alpha2
(was: JDG 7.0.0 ER5)
> Container does not restart after clicking "restart now" in Thread Pools tab
> ---------------------------------------------------------------------------
>
> Key: ISPN-6705
> URL: https://issues.jboss.org/browse/ISPN-6705
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 9.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Minor
>
> Container configuration page "Thread pools" tab.
> After changing a value e.g. "Async operation" -> "max threads" and -> click "save" -> click "Restart now" the container does not restart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6522) Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6522?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6522:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4254, https://github.com/infinispan/infinispan/pull/4372 (was: https://github.com/infinispan/infinispan/pull/4254)
> Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6522
> URL: https://issues.jboss.org/browse/ISPN-6522
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, WildFly modules
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
> Fix For: 9.0.0.Alpha3, 8.2.3.Final
>
>
> The Hibernate Search engine detects if the elasticsearch backend is on the classpath,
> and if so, adds {{o.h.s.backend.elasticsearch.impl.ElasticsearchBridgeProvider}} to the top of the list of the annotation based bridge providers.
> When processing an entity with a @DateBridge annotation, it picks the elasticsearch provider to converted from/to {{Date}} objects (since it has priority) which in turn fails with the exception:
> {code}
> org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.convertToString(ElasticsearchBridgeProvider.java:71)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.set(ElasticsearchBridgeProvider.java:54)
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$OneWayConversionContextImpl.set(ContextualExceptionBridgeHelper.java:110)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.buildDocumentFieldsForProperties(DocumentBuilderIndexedEntity.java:626)
> {code}
>
> This exception happens only when using the infinispan modules, where the elasticsearch backend is added as a dependency; in embedded mode the aforementioned provider is not loaded since the elasticsearch is not on the classpath.
> This current behaviour is not the best for two reasons:
> * When using Wildlfy modules, the elasticsearch backend is marked as optional, but still, it's visible in the classpath and gets loaded
> * If the user is not using the elasticsearch backend, but the jar is on the classpath, elasticsearch date conversion will take precedence over the built-in bridge providers, and it shouldn't
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6522) Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6522?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6522:
------------------------------------
Fix Version/s: 9.0.0.Alpha3
8.2.3.Final
> Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6522
> URL: https://issues.jboss.org/browse/ISPN-6522
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, WildFly modules
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
> Fix For: 9.0.0.Alpha3, 8.2.3.Final
>
>
> The Hibernate Search engine detects if the elasticsearch backend is on the classpath,
> and if so, adds {{o.h.s.backend.elasticsearch.impl.ElasticsearchBridgeProvider}} to the top of the list of the annotation based bridge providers.
> When processing an entity with a @DateBridge annotation, it picks the elasticsearch provider to converted from/to {{Date}} objects (since it has priority) which in turn fails with the exception:
> {code}
> org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.convertToString(ElasticsearchBridgeProvider.java:71)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.set(ElasticsearchBridgeProvider.java:54)
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$OneWayConversionContextImpl.set(ContextualExceptionBridgeHelper.java:110)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.buildDocumentFieldsForProperties(DocumentBuilderIndexedEntity.java:626)
> {code}
>
> This exception happens only when using the infinispan modules, where the elasticsearch backend is added as a dependency; in embedded mode the aforementioned provider is not loaded since the elasticsearch is not on the classpath.
> This current behaviour is not the best for two reasons:
> * When using Wildlfy modules, the elasticsearch backend is marked as optional, but still, it's visible in the classpath and gets loaded
> * If the user is not using the elasticsearch backend, but the jar is on the classpath, elasticsearch date conversion will take precedence over the built-in bridge providers, and it shouldn't
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years