[JBoss JIRA] (ISPN-6685) Hot Rod server failed to start due to NPE in PersistenceManagerImpl.preload()
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-6685:
---------------------------------------
Summary: Hot Rod server failed to start due to NPE in PersistenceManagerImpl.preload()
Key: ISPN-6685
URL: https://issues.jboss.org/browse/ISPN-6685
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.0.0.Alpha2
Reporter: Gustavo Fernandes
This occurs intermittently during the Spark connector testsuite, that starts 3 servers in parallel. The HotRod server fails to start with error:
{noformat}
2016-05-19 19:31:21,976 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datagrid-infinispan-endpoint"),
("hotrod-connector" => "hotrod-connector")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.datagrid-infinispan-endpoint.hotrod.hotrod-connector" => "org.jboss.msc.service.StartException in service jboss.datagrid-infinispan-endpoint.hotrod.hotrod-connector: DGENDPT10004: Failed to start HotRodServer
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
Caused by: java.util.concurrent.ExecutionException: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
Caused by: java.lang.NullPointerException"}}
2016-05-19 19:31:22,037 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.datagrid-infinispan-endpoint.hotrod.hotrod-connector: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan-endpoint.hotrod.hotrod-connector: DGENDPT10004: Failed to start HotRodServer
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6680) InterruptedException during PutAll from Hot Rod client prevents failover
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6680?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-6680:
---------------------------------------
Assignee: Gustavo Fernandes
> InterruptedException during PutAll from Hot Rod client prevents failover
> ------------------------------------------------------------------------
>
> Key: ISPN-6680
> URL: https://issues.jboss.org/browse/ISPN-6680
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha2
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.Alpha3
>
>
> The server throws an InterruptedException during the PutAllCommand:
> {noformat}
> 2016-05-19 10:28:06,407 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRodServerHandler-4-22) ISPN000136: Error executing command PutMapCommand, writing keys [[B0x034b0000005a, [B0x034b0000005d, [B0x034b0000005b, [B0x034b0000005c, [B0x034b0000005e]: java.lang.InterruptedException
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:347)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1907)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutMapCommand(NonTxDistributionInterceptor.java:201)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutMapCommand(NonTxDistributionInterceptor.java:67)
> at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:68)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.doInvokeNextSync(BaseSequentialInvocationContext.java:265)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.forkInvocationSync(BaseSequentialInvocationContext.java:90)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:515)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForPutMapCommand(EntryWrappingInterceptor.java:563)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutMapCommand(EntryWrappingInterceptor.java:311)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutMapCommand(EntryWrappingInterceptor.java:77)
> at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:68)
> at org.infinispan.interceptors.impl.BaseSequentialInvocationContext.doInvokeNextSync(BaseSequentialInvocationContext.java:265)
> {noformat}
> That gets propagated to the client that does not recover from the error:
> {noformat}
> org.infinispan.client.hotrod.exceptions.ParallelOperationException:: java.util.concurrent.ExecutionException: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=218 returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.InterruptedException
> java.lang.InterruptedException
> at org.infinispan.client.hotrod.impl.operations.ParallelHotRodOperation.executeParallel(ParallelHotRodOperation.java:79)
> at org.infinispan.client.hotrod.impl.operations.ParallelHotRodOperation.execute(ParallelHotRodOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putAll(RemoteCacheImpl.java:223)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.putAll(RemoteCacheSupport.java:49)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6574:
-----------------------------------------------
wfink(a)redhat.com changed the Status of [bug 1332924|https://bugzilla.redhat.com/show_bug.cgi?id=1332924] from NEW to POST
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6684) Disable editing template name/type when editing existing templates
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6684?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6684:
-------------------------------
Summary: Disable editing template name/type when editing existing templates (was: Disable editing template name/type when editing a template)
> Disable editing template name/type when editing existing templates
> ------------------------------------------------------------------
>
> Key: ISPN-6684
> URL: https://issues.jboss.org/browse/ISPN-6684
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 9.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> in cache container configuration -> templates tab -> click edit on any template -> change "template" to e.g. EDITED_TEMPLATE and a error window will pop up. To prevent this we will disable editing of template name/type.
> See comments on JDG-305 for more details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6651) Reduce WARN verbosiness due to missing netty native transport
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6651?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6651:
------------------------------------
Summary: Reduce WARN verbosiness due to missing netty native transport (was: Reduce WARN verbosiness due to missing netty native tranport)
> Reduce WARN verbosiness due to missing netty native transport
> -------------------------------------------------------------
>
> Key: ISPN-6651
> URL: https://issues.jboss.org/browse/ISPN-6651
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Minor
> Fix For: 9.0.0.Alpha3, 8.2.3.Final
>
>
> Currently the full stack trace is printed for each of the endpoints, when starting the server on a Linux that does not support Netty's native transport, for example, on Alpine Linux (not GLIBC based)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6173) NotSerializableException while executing streams via JavaScript in a cluster in DIST mode
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6173?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-6173 at 5/19/16 11:36 AM:
---------------------------------------------------------------
Here is conversation we had prior regarding this issue
{code}
Feb 03 09:35:42 <amanukya_wfh> ttarrant, ping
Feb 03 09:37:07 <amanukya_wfh> ttarrant, I have tried with Java.extend(), the script compilation is ok, from trace logs seems that the script execution is also fine, but when I am calling get() method on the future task, it throws java.util.concurrent.CancellationException
Feb 03 09:37:18 <amanukya_wfh> ttarrant, from tracelogs I can see that it throws the following exception:
Feb 03 09:37:32 <amanukya_wfh> ttarrant, java.io.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
Feb 03 09:38:01 <amanukya_wfh> ttarrant, if I understand correctly, this exception is thrown when app tries to write the result back with marshaller
Feb 03 09:38:25 <amanukya_wfh> ttarrant, now I'm thinking maybe I need to provide a marshaller in system bindings?
Feb 03 09:41:21 <amanukya_wfh> ttarrant, the script looks like http://pastebin.test.redhat.com/345851
Feb 03 09:43:27 <amanukya_wfh> ttarrant, and the exception looks like: http://pastebin.test.redhat.com/345855
Feb 03 09:55:20 <ttarrant> wburns, can you look into amanukya_wfh's js streams ?
Feb 03 10:00:50 <wburns> ttarrant: looking
Feb 03 10:06:39 <wburns> ttarrant, amanukya_wfh: it is trying to serialize the map function instance provided - unfortunately I am not familiar with JS to know where the BoundMethodHandle is coming from
Feb 03 10:07:41 <wburns> amanukya_wfh: have you gotten anything to work yet or this is the first attempt?
Feb 03 10:11:26 <amanukya_wfh> wburns, ttarrant this script works properly in REPL_SYNC cluster, but it gives the exception provided above in DIST_SYNC mode
Feb 03 10:12:15 <wburns> amanukya_wfh: odd REPL should be serializing it as well
Feb 03 10:16:12 <amanukya_wfh> wburns, in REPL the scripts even work without Java.extend(Serializable, Function) .. no matter mode is set to local or distributed
Feb 03 10:22:18 <wburns> amanukya_wfh: nvm I was mistaken - I thought I had changed that guess not :)
Feb 03 10:22:40 <wburns> amanukya_wfh: REPL will work the same as LOCAL
Feb 03 10:24:04 <wburns> amanukya_wfh: it seems the serializable instance has a field in it which is not serializable which kinda defeats the purpose of being serializable :P
Feb 03 10:24:42 <wburns> amanukya_wfh: did you try tweaking your new to be like this http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html ?
Feb 03 10:26:00 <wburns> amanukya_wfh: like http://pastebin.test.redhat.com/345881
Feb 03 10:29:59 <amanukya_wfh> wburns, thanks - looks better than it was before :)
Feb 03 10:30:09 <wburns> amanukya_wfh: worked?
Feb 03 10:30:17 <amanukya_wfh> wburns, but anyway the execution gives the same exception
Feb 03 10:30:34 <wburns> amanukya_wfh: same exact thing?
Feb 03 10:30:44 <amanukya_wfh> wburns, yes - org.infinispan.commons.marshall.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
Feb 03 10:30:59 <wburns> amanukya_wfh: can you send in paste, want to make sure it isn't another spot
Feb 03 10:31:21 <wburns> amanukya_wfh: seems odd Oracle would link how to make it Serializable in their doc, but you can't actually serialize it, heh
Feb 03 10:32:10 <amanukya_wfh> wburns, uhu
Feb 03 10:32:28 <wburns> amanukya_wfh: the entire stack trace
Feb 03 10:36:11 <amanukya_wfh> wburns, the same as it was before, here is the stacktrace for the execution with the tweaked new: http://pastebin.test.redhat.com/345886
Feb 03 10:37:19 <wburns> amanukya_wfh: no it is slightly different
Feb 03 10:37:50 <wburns> amanukya_wfh: nvm sorry mislooked
Feb 03 10:42:44 <wburns> amanukya_wfh: can you try http://pastebin.test.redhat.com/345890 ?
Feb 03 10:42:53 <wburns> amanukya_wfh: I have no idea if that will work as it is Java code in there :P
Feb 03 10:45:00 <wburns> amanukya_wfh: basically testing if regular java serialization will work on it
Feb 03 10:45:10 <amanukya_wfh> wburns, trying
Feb 03 10:53:30 <amanukya_wfh> wburns, it gives the same NotSerializableException but the stacktrace is different: http://pastebin.test.redhat.com/345899
Feb 03 10:54:30 <wburns> amanukya_wfh: just wanted to rule out jboss marshalling
Feb 03 10:55:44 <wburns> amanukya_wfh: unfortunately I am stumped - google doesn't find much on this :(
Feb 03 10:56:03 <wburns> amanukya_wfh: confused why oracle doc would show how to make something serializable but not actually let it be serializable
Feb 03 11:01:38 <amanukya_wfh> wburns, I also cannot find anything related in google
Feb 03 11:03:03 <wburns> amanukya_wfh: btw how are you running?
Feb 03 11:03:14 <wburns> amanukya_wfh: just using ScriptEngineManager and starting up the Cache in a main?
Feb 03 11:04:47 <amanukya_wfh> wburns, I have test similiar to org.infinispan.scripting.ClusteredScriptingTest, which loads the script and runs it
Feb 03 11:05:03 <richa> wfink: added the tag you will now be able to see 6.6.1 release
Feb 03 11:05:25 <amanukya_wfh> wburns, the only thing that I have found in internet, which has some mention about seriailzing, is this pull request - http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/53edf7f3f10c
Feb 03 11:05:33 <amanukya_wfh> wburns, but seems that this is for jdk9
Feb 03 11:41:55 <amanukya_wfh> wburns, ttarrant - so what should I do now? open a bug with detailed description, so that we can continue the investigation in it's scope?
Feb 03 11:45:50 * joshuaw (~josh(a)vpn-58-235.rdu2.redhat.com) has left #jdg
Feb 03 11:46:33 <wburns> amanukya_wfh: ttarrant would know for sure, but it seems fine to me
Feb 03 11:49:07 <amanukya_wfh> wburns, you mean the option of opening the bug, right?
Feb 03 11:49:18 <wburns> amanukya_wfh: yeah
Feb 03 11:51:54 <amanukya_wfh> wburns, ok and thank you for helping withFeb 03 10:42:44 <wburns> amanukya_wfh: can you try http://pastebin.test.redhat.com/345890 ?
Feb 03 10:42:53 <wburns> amanukya_wfh: I have no idea if that will work as it is Java code in there :P
Feb 03 10:45:00 <wburns> amanukya_wfh: basically testing if regular java serialization will work on it
Feb 03 10:45:10 <amanukya_wfh> wburns, trying
Feb 03 10:53:30 <amanukya_wfh> wburns, it gives the same NotSerializableException but the stacktrace is different: http://pastebin.test.redhat.com/345899
Feb 03 10:54:30 <wburns> amanukya_wfh: just wanted to rule out jboss marshalling
Feb 03 10:55:44 <wburns> amanukya_wfh: unfortunately I am stumped - google doesn't find much on this :(
Feb 03 10:56:03 <wburns> amanukya_wfh: confused why oracle doc would show how to make something serializable but not actually let it be serializable
Feb 03 11:01:38 <amanukya_wfh> wburns, I also cannot find anything related in google
Feb 03 11:03:03 <wburns> amanukya_wfh: btw how are you running?
Feb 03 11:03:14 <wburns> amanukya_wfh: just using ScriptEngineManager and starting up the Cache in a main?
Feb 03 11:04:47 <amanukya_wfh> wburns, I have test similiar to org.infinispan.scripting.ClusteredScriptingTest, which loads the script and runs it
Feb 03 11:05:03 <richa> wfink: added the tag you will now be able to see 6.6.1 release
Feb 03 11:05:25 <amanukya_wfh> wburns, the only thing that I have found in internet, which has some mention about seriailzing, is this pull request - http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/53edf7f3f10c
Feb 03 11:05:33 <amanukya_wfh> wburns, but seems that this is for jdk9
Feb 03 11:41:55 <amanukya_wfh> wburns, ttarrant - so what should I do now? open a bug with detailed description, so that we can continue the investigation in it's scope?
Feb 03 11:46:33 <wburns> amanukya_wfh: ttarrant would know for sure, but it seems fine to me
Feb 03 11:49:07 <amanukya_wfh> wburns, you mean the option of opening the bug, right?
Feb 03 11:49:18 <wburns> amanukya_wfh: yeah
Feb 03 11:51:54 <amanukya_wfh> wburns, ok and thank you for helping with this issue investigation
Feb 03 11:52:41 <wburns> amanukya_wfh: yeah sorry I am not a js expert or this issue investigation
Feb 03 11:55:07 <amanukya_wfh> wburns, me too :) it is only a month that I am back from maternity leave. Now learning and remembering everything from past
Feb 03 12:36:21 <amanukya_wfh> ttarrant, I have reported https://issues.jboss.org/browse/ISPN-6173
{code}
The link to oracle talking about how to extend Serializable is http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
was (Author: william.burns):
Here is conversation we had prior regarding this issue
{code}
Feb 03 09:35:42 <amanukya_wfh> ttarrant, ping
Feb 03 09:37:07 <amanukya_wfh> ttarrant, I have tried with Java.extend(), the script compilation is ok, from trace logs seems that the script execution is also fine, but when I am calling get() method on the future task, it throws java.util.concurrent.CancellationException
Feb 03 09:37:18 <amanukya_wfh> ttarrant, from tracelogs I can see that it throws the following exception:
Feb 03 09:37:32 <amanukya_wfh> ttarrant, java.io.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
Feb 03 09:38:01 <amanukya_wfh> ttarrant, if I understand correctly, this exception is thrown when app tries to write the result back with marshaller
Feb 03 09:38:25 <amanukya_wfh> ttarrant, now I'm thinking maybe I need to provide a marshaller in system bindings?
Feb 03 09:41:21 <amanukya_wfh> ttarrant, the script looks like http://pastebin.test.redhat.com/345851
Feb 03 09:43:27 <amanukya_wfh> ttarrant, and the exception looks like: http://pastebin.test.redhat.com/345855
Feb 03 09:55:20 <ttarrant> wburns, can you look into amanukya_wfh's js streams ?
Feb 03 10:00:50 <wburns> ttarrant: looking
Feb 03 10:06:39 <wburns> ttarrant, amanukya_wfh: it is trying to serialize the map function instance provided - unfortunately I am not familiar with JS to know where the BoundMethodHandle is coming from
Feb 03 10:07:41 <wburns> amanukya_wfh: have you gotten anything to work yet or this is the first attempt?
Feb 03 10:11:26 <amanukya_wfh> wburns, ttarrant this script works properly in REPL_SYNC cluster, but it gives the exception provided above in DIST_SYNC mode
Feb 03 10:12:15 <wburns> amanukya_wfh: odd REPL should be serializing it as well
Feb 03 10:16:12 <amanukya_wfh> wburns, in REPL the scripts even work without Java.extend(Serializable, Function) .. no matter mode is set to local or distributed
Feb 03 10:22:18 <wburns> amanukya_wfh: nvm I was mistaken - I thought I had changed that guess not :)
Feb 03 10:22:40 <wburns> amanukya_wfh: REPL will work the same as LOCAL
Feb 03 10:24:04 <wburns> amanukya_wfh: it seems the serializable instance has a field in it which is not serializable which kinda defeats the purpose of being serializable :P
Feb 03 10:24:42 <wburns> amanukya_wfh: did you try tweaking your new to be like this http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html ?
Feb 03 10:26:00 <wburns> amanukya_wfh: like http://pastebin.test.redhat.com/345881
Feb 03 10:29:59 <amanukya_wfh> wburns, thanks - looks better than it was before :)
Feb 03 10:30:09 <wburns> amanukya_wfh: worked?
Feb 03 10:30:17 <amanukya_wfh> wburns, but anyway the execution gives the same exception
Feb 03 10:30:34 <wburns> amanukya_wfh: same exact thing?
Feb 03 10:30:44 <amanukya_wfh> wburns, yes - org.infinispan.commons.marshall.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
Feb 03 10:30:59 <wburns> amanukya_wfh: can you send in paste, want to make sure it isn't another spot
Feb 03 10:31:21 <wburns> amanukya_wfh: seems odd Oracle would link how to make it Serializable in their doc, but you can't actually serialize it, heh
Feb 03 10:32:10 <amanukya_wfh> wburns, uhu
Feb 03 10:32:28 <wburns> amanukya_wfh: the entire stack trace
Feb 03 10:36:11 <amanukya_wfh> wburns, the same as it was before, here is the stacktrace for the execution with the tweaked new: http://pastebin.test.redhat.com/345886
Feb 03 10:37:19 <wburns> amanukya_wfh: no it is slightly different
Feb 03 10:37:50 <wburns> amanukya_wfh: nvm sorry mislooked
Feb 03 10:42:44 <wburns> amanukya_wfh: can you try http://pastebin.test.redhat.com/345890 ?
Feb 03 10:42:53 <wburns> amanukya_wfh: I have no idea if that will work as it is Java code in there :P
Feb 03 10:45:00 <wburns> amanukya_wfh: basically testing if regular java serialization will work on it
Feb 03 10:45:10 <amanukya_wfh> wburns, trying
Feb 03 10:53:30 <amanukya_wfh> wburns, it gives the same NotSerializableException but the stacktrace is different: http://pastebin.test.redhat.com/345899
Feb 03 10:54:30 <wburns> amanukya_wfh: just wanted to rule out jboss marshalling
Feb 03 10:55:01 * crobson (~crobson(a)10.18.33.23) has joined #jdg
Feb 03 10:55:44 <wburns> amanukya_wfh: unfortunately I am stumped - google doesn't find much on this :(
Feb 03 10:56:03 <wburns> amanukya_wfh: confused why oracle doc would show how to make something serializable but not actually let it be serializable
Feb 03 11:01:30 * jpallich_ (~jpallich(a)10.34.250.14) has joined #jdg
Feb 03 11:01:38 <amanukya_wfh> wburns, I also cannot find anything related in google
Feb 03 11:01:39 * jpallich_ is now known as jpallich_mtg
Feb 03 11:02:21 * rpulluru|Dinner is now known as rpulluru
Feb 03 11:03:03 <wburns> amanukya_wfh: btw how are you running?
Feb 03 11:03:14 <wburns> amanukya_wfh: just using ScriptEngineManager and starting up the Cache in a main?
Feb 03 11:04:15 * c-huff|mtg is now known as c-huff
Feb 03 11:04:47 <amanukya_wfh> wburns, I have test similiar to org.infinispan.scripting.ClusteredScriptingTest, which loads the script and runs it
Feb 03 11:04:53 * mvrabel has quit (Ping timeout: 622 seconds)
Feb 03 11:05:03 <richa> wfink: added the tag you will now be able to see 6.6.1 release
Feb 03 11:05:25 <amanukya_wfh> wburns, the only thing that I have found in internet, which has some mention about seriailzing, is this pull request - http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/53edf7f3f10c
Feb 03 11:05:33 <amanukya_wfh> wburns, but seems that this is for jdk9
Feb 03 11:06:09 * vjuranek has quit (Ping timeout: 624 seconds)
Feb 03 11:07:30 * shakil has quit (Ping timeout: 624 seconds)
Feb 03 11:08:51 * jpallich has quit (Ping timeout: 624 seconds)
Feb 03 11:08:55 * slaskawi has quit (Quit: Leaving)
Feb 03 11:15:49 * mgencur has quit (Quit: Leaving.)
Feb 03 11:23:02 * shakil (~ssiddiqu(a)vpn-58-117.rdu2.redhat.com) has joined #jdg
Feb 03 11:32:02 * emmanuel is now known as emmanuel_off
Feb 03 11:34:16 * mcimbora has quit (Quit: Leaving.)
Feb 03 11:36:26 * anistor has quit (Quit: Leaving.)
Feb 03 11:36:45 * mszynkie has quit (Ping timeout: 624 seconds)
Feb 03 11:41:55 <amanukya_wfh> wburns, ttarrant - so what should I do now? open a bug with detailed description, so that we can continue the investigation in it's scope?
Feb 03 11:45:50 * joshuaw (~josh(a)vpn-58-235.rdu2.redhat.com) has left #jdg
Feb 03 11:46:33 <wburns> amanukya_wfh: ttarrant would know for sure, but it seems fine to me
Feb 03 11:47:35 * Bobb has quit (Ping timeout: 600 seconds)
Feb 03 11:47:48 * jpallich_mtg is now known as jpallich
Feb 03 11:49:07 <amanukya_wfh> wburns, you mean the option of opening the bug, right?
Feb 03 11:49:18 <wburns> amanukya_wfh: yeah
Feb 03 11:51:28 * vchintal (~vchintal(a)dhcp-16-170.sjc.redhat.com) has joined #jdg
Feb 03 11:51:54 <amanukya_wfh> wburns, ok and thank you for helping withFeb 03 10:42:44 <wburns> amanukya_wfh: can you try http://pastebin.test.redhat.com/345890 ?
Feb 03 10:42:53 <wburns> amanukya_wfh: I have no idea if that will work as it is Java code in there :P
Feb 03 10:43:25 * rmacor has quit (Quit: Leaving.)
Feb 03 10:45:00 <wburns> amanukya_wfh: basically testing if regular java serialization will work on it
Feb 03 10:45:10 <amanukya_wfh> wburns, trying
Feb 03 10:53:30 <amanukya_wfh> wburns, it gives the same NotSerializableException but the stacktrace is different: http://pastebin.test.redhat.com/345899
Feb 03 10:54:30 <wburns> amanukya_wfh: just wanted to rule out jboss marshalling
Feb 03 10:55:44 <wburns> amanukya_wfh: unfortunately I am stumped - google doesn't find much on this :(
Feb 03 10:56:03 <wburns> amanukya_wfh: confused why oracle doc would show how to make something serializable but not actually let it be serializable
Feb 03 11:01:38 <amanukya_wfh> wburns, I also cannot find anything related in google
Feb 03 11:03:03 <wburns> amanukya_wfh: btw how are you running?
Feb 03 11:03:14 <wburns> amanukya_wfh: just using ScriptEngineManager and starting up the Cache in a main?
Feb 03 11:04:47 <amanukya_wfh> wburns, I have test similiar to org.infinispan.scripting.ClusteredScriptingTest, which loads the script and runs it
Feb 03 11:05:03 <richa> wfink: added the tag you will now be able to see 6.6.1 release
Feb 03 11:05:25 <amanukya_wfh> wburns, the only thing that I have found in internet, which has some mention about seriailzing, is this pull request - http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/53edf7f3f10c
Feb 03 11:05:33 <amanukya_wfh> wburns, but seems that this is for jdk9
Feb 03 11:41:55 <amanukya_wfh> wburns, ttarrant - so what should I do now? open a bug with detailed description, so that we can continue the investigation in it's scope?
Feb 03 11:46:33 <wburns> amanukya_wfh: ttarrant would know for sure, but it seems fine to me
Feb 03 11:49:07 <amanukya_wfh> wburns, you mean the option of opening the bug, right?
Feb 03 11:49:18 <wburns> amanukya_wfh: yeah
Feb 03 11:51:54 <amanukya_wfh> wburns, ok and thank you for helping with this issue investigation
Feb 03 11:52:41 <wburns> amanukya_wfh: yeah sorry I am not a js expert or this issue investigation
Feb 03 11:55:07 <amanukya_wfh> wburns, me too :) it is only a month that I am back from maternity leave. Now learning and remembering everything from past
Feb 03 12:36:21 <amanukya_wfh> ttarrant, I have reported https://issues.jboss.org/browse/ISPN-6173
{code}
The link to oracle talking about how to extend Serializable is http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
> NotSerializableException while executing streams via JavaScript in a cluster in DIST mode
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6173
> URL: https://issues.jboss.org/browse/ISPN-6173
> Project: Infinispan
> Issue Type: Bug
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha3, 9.0.0.Final
>
> Attachments: wordCountStream_Exec.js
>
>
> The following exception appears when I try to execute a JS script which uses Java Stream API on 4 node cluster in DIST_SYNC mode. No matter which mode is set in JS metadata (local or distributed) the test ends with exception.
> You can find the test and the script here:
> https://github.com/andyuk1986/infinispan/blob/2e19b65a00d962201c81216ca3b...
> https://github.com/andyuk1986/infinispan/blob/2e19b65a00d962201c81216ca3b...
> When the mode=local, the exception is:
> {code}
> org.infinispan.commons.marshall.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
> Caused by: an exception which occurred:
> in field apply
> in object jdk.nashorn.javaadapters.java.util.function.Function$$Serializable@5e828108
> -> toString = jdk.nashorn.javaadapters.java.util.function.Function$$Serializable@5e828108
> in object java.util.ArrayDeque@7074aba7
> -> toString = [org.infinispan.stream.impl.intops.object.MapOperation@11cc7142]
> in object org.infinispan.stream.impl.termop.SegmentRetryingOperation@70414f65
> -> toString = org.infinispan.stream.impl.termop.SegmentRetryingOperation@70414f65
> in object org.infinispan.stream.impl.StreamRequestCommand@38614d0c
> -> toString = StreamRequestCommand{cacheName='___defaultcache'}
> {code}
> When the mode=distributed, the exception is:
> {code}
> java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
> at org.infinispan.scripting.DistributedCacheScriptingTest.testDistributedMapReduceStream(DistributedCacheScriptingTest.java:61)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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: java.util.concurrent.CancellationException
> at java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2263)
> at org.infinispan.util.concurrent.CompletableFutures.lambda$toCompletableFuture$16(CompletableFutures.java:49)
> at org.infinispan.commons.util.concurrent.BaseNotifyingFuture.fireListeners(BaseNotifyingFuture.java:37)
> at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.notifyException(NotifyingFutureImpl.java:105)
> at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart$1.doLocalInvoke(DefaultExecutorService.java:1117)
> at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart$1.call(DefaultExecutorService.java:1103)
> ... 4 more
> {code}
> But for both cases, from the TRACE logs the real exception is:
> {code}
> java.io.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.infinispan.stream.impl.intops.IntermediateOperationExternalizer.writeObject(IntermediateOperationExternalizer.java:194) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.intops.IntermediateOperationExternalizer.writeObject(IntermediateOperationExternalizer.java:23) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:481) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:138) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:569) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.infinispan.stream.impl.termop.TerminalOperationExternalizer.writeObject(TerminalOperationExternalizer.java:83) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.termop.TerminalOperationExternalizer.writeObject(TerminalOperationExternalizer.java:34) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:481) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:138) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:66) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.marshallParameters(CacheRpcCommandExternalizer.java:128) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:112) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:68) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:481) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:138) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111) ~[jboss-marshalling-osgi-1.4.10.Final.jar:1.4.10.Final]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:72) ~[infinispan-commons-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41) [infinispan-commons-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85) [infinispan-commons-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:247) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:265) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:121) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:578) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:162) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.ClusterStreamManagerImpl.submitAsyncTasks(ClusterStreamManagerImpl.java:169) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.ClusterStreamManagerImpl.commonRemoteStreamOperation(ClusterStreamManagerImpl.java:86) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.ClusterStreamManagerImpl.remoteStreamOperationRehashAware(ClusterStreamManagerImpl.java:70) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.AbstractCacheStream.performOperationRehashAware(AbstractCacheStream.java:306) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.AbstractCacheStream.performOperation(AbstractCacheStream.java:258) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.stream.impl.DistributedCacheStream.collect(DistributedCacheStream.java:329) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at jdk.nashorn.internal.scripts.Script$\^eval\_.:program(<eval>:23) [?:?]
> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:640) [nashorn.jar:?]
> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:228) [nashorn.jar:?]
> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) [nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:418) [nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:73) [nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:511) [nashorn.jar:?]
> at javax.script.CompiledScript.eval(CompiledScript.java:92) [?:1.8.0_66]
> at org.infinispan.scripting.impl.ScriptingManagerImpl.execute(ScriptingManagerImpl.java:182) [classes/:?]
> at org.infinispan.scripting.impl.DistributedScript.call(DistributedScript.java:30) [classes/:?]
> at org.infinispan.commands.read.DistributedExecuteCommand.perform(DistributedExecuteCommand.java:103) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart$1.doLocalInvoke(DefaultExecutorService.java:1113) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart$1.call(DefaultExecutorService.java:1103) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_66]
> Caused by: org.jboss.marshalling.TraceInformation
> {code}
> Seems that this is general Nashorn thing, as complex object serialization also gives the same exception. E.g the following script execution throws same exception with a bit different stack trace:
> {code}
> // mode=distributed,language=javascript
> var Function = Java.type("java.util.function.Function")
> var Serializable = Java.type("java.io.Serializable")
> var SerializableFunction = Java.extend(Function, Serializable);
> var CollectionsAndFiles = new JavaImporter(
> java.util,
> java.io,
> java.nio);
> var e = new SerializableFunction( {
> apply: function(object) {
> return object.getValue().toLowerCase().split(/[\\W]+/)
> }
> })
> with (CollectionsAndFiles) {
> var bos = new ByteArrayOutputStream();
> var out = null;
> try {
> out = new ObjectOutputStream(bos);
> out.writeObject(e);
> var yourBytes = bos.toByteArray();
> } finally {
> try {
> if (out != null) {
> out.close();
> }
> } finally {
> }
> }
> }
> {code}
> the stacktrace for the code above is:
> {code}
> java.lang.RuntimeException: java.io.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:397) ~[nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:446) ~[nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:403) ~[nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:399) ~[nashorn.jar:?]
> at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155) ~[nashorn.jar:?]
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233) ~[?:1.8.0_66]
> at org.infinispan.scripting.impl.ScriptingManagerImpl.execute(ScriptingManagerImpl.java:186) ~[classes/:?]
> at org.infinispan.scripting.impl.DistributedScript.call(DistributedScript.java:30) ~[classes/:?]
> at org.infinispan.commands.read.DistributedExecuteCommand.perform(DistributedExecuteCommand.java:103) ~[infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) [infinispan-core-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_66]
> Caused by: java.io.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_LL
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184) ~[?:1.8.0_66]
> at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) ~[?:1.8.0_66]
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) ~[?:1.8.0_66]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432) ~[?:1.8.0_66]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178) ~[?:1.8.0_66]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) ~[?:1.8.0_66]
> at jdk.nashorn.internal.scripts.Script$2$\^eval\_.:program(<eval>:21) ~[?:?]
> at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:640) ~[nashorn.jar:?]
> at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:228) ~[nashorn.jar:?]
> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) ~[nashorn.jar:?]
> ... 13 more
> {code}
> UPDATE:
> In case when the test tries to execute javascript where the mode is set to local, and the map/reduce is executed using submitConsumer(...) method of the cacheManager's executor, the following exception is thrown:
> {code}
> java.util.concurrent.CompletionException: java.lang.ClassCastException: Cannot cast org.infinispan.manager.DefaultCacheManager to java.util.function.Function
> org.infinispan.commons.marshall.NotSerializableException: java.lang.invoke.BoundMethodHandle$Species_L3
> Caused by: an exception which occurred:
> in field apply
> in object jdk.nashorn.javaadapters.java.util.function.Function$$Serializable@1ad8df52
> -> toString = jdk.nashorn.javaadapters.java.util.function.Function$$Serializable@1ad8df52
> in object org.infinispan.manager.impl.ReplicableCommandManagerFunction@a52ca2e
> -> toString = org.infinispan.manager.impl.ReplicableCommandManagerFunction@a52ca2e
> {code}
> The code is attached wordCountStream_Exec.js.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months