[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev commented on WFLY-13444:
------------------------------------
Hi [~pferraro],
Just added below snapshot using visual VM. Let me know in case if anything needs to be addressed for avoiding this thread invocation in Wildfly. Not sure who is triggering this thread.
!stack trace from snapshot.PNG|thumbnail!
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, IO
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev updated WFLY-13444:
-------------------------------
Attachment: stack trace from snapshot.PNG
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, IO
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13446) Dependency of wildfly-weld-common would be better to be ${project.groupId}
by Lin Gao (Jira)
Lin Gao created WFLY-13446:
------------------------------
Summary: Dependency of wildfly-weld-common would be better to be ${project.groupId}
Key: WFLY-13446
URL: https://issues.redhat.com/browse/WFLY-13446
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: Lin Gao
Assignee: Lin Gao
A new depenency :
{code:xml}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-weld-common</artifactId>
</dependency>
{code}
was added to +ejb3/+ subsystem. The dependency comes from different module of the same project, so it is better to have the groupId to +${project.groupId}+, so that it is easier when updating the project's groupId to like: +org.jboss.eap+
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13432) Provide capability for Undertow HTTP Upgrade registry
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13432?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13432 at 5/10/20 12:00 PM:
----------------------------------------------------------------------
The HTTP Upgrade feature of Undertow depends on other subsystems having access to a Value service defined in the Undertow HttpListenerResource. The ServiceName is JBOSS."http-upgrade-registry" and the value returned is ChannelUpgradeHandler. The ChannelUpgradeHandler is used by other subsystems to plug-in specific pieces to allow an HTTP Upgrade to a specific protocol to take place. Every HTTP request passes through the ChannelUpgradeHandler and so every request has the possibility to upgrade, depending on the content of the HTTP message headers.
This is used by other subsystems (remoting, host-controller, and server in Wildfly core, and messaging-activemq in Wildfly) and currently does not make use of capabilities.
I added a capability HTTP_UPGRADE_REGISTRY_CAPABILIY in HttpListenerResourceDefinition and used it to generate the ServiceName for the Value service. Because other subsystems still rely on the old ServiceName, I added that ServiceName as an alias when building the service so that the other subsystems would not be affected. Thanks to Paul F. for helping out with that!
was (Author: rachmato):
The HTTP Upgrade feature of Undertow depends on other subsystems having access to a Value service defined in the Undertow HttpListenerResource. The ServiceName is JBOSS."http-upgrade-registry" and the value returned is ChannelUpgradeHandler. The ChannelUpgradeHandler is used by other subsystems to plug-in specific pieces to allow an HTTP Upgrade to a specific protocol to take place. Every HTTP request passes through the ChannelUpgradeHandler and so every request has the possibility to upgrade, depending on the content of the HTTP message headers.
This is used by other subsystems (remoting, host-controller, and server in Wildfly core, and messaging-activemq in Wildfly) and currently does no make use of capabilities.
I added a capability HTTP_UPGRADE_REGISTRY_CAPABILIY in HttpListenerResourceDefinition and used it to generate the ServiceName for the Value service. Because other subsystems still rely on the old ServiceName, I added that ServiceName as an alias when building the service so that the other subsystems would not be affected. Thanks to Paul F. for helping out with that!
> Provide capability for Undertow HTTP Upgrade registry
> -----------------------------------------------------
>
> Key: WFLY-13432
> URL: https://issues.redhat.com/browse/WFLY-13432
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> The HTTP Upgrade feature of Undertow depends on subsystems such as Remoting and Messaging having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13432) Provide capability for Undertow HTTP Upgrade registry
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13432?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13432:
---------------------------------------
Description: The HTTP Upgrade feature of Undertow depends on subsystems such as Remoting and Messaging having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities. (was: The HTTP Upgrade feature of Undertow depends on subsystems such as Messaging and EJB having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.)
> Provide capability for Undertow HTTP Upgrade registry
> -----------------------------------------------------
>
> Key: WFLY-13432
> URL: https://issues.redhat.com/browse/WFLY-13432
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> The HTTP Upgrade feature of Undertow depends on subsystems such as Remoting and Messaging having access to a registry of upgrade protocols (ChannelUpgradeHandler) provided by Undertow. This needs to be updated to use capabilities.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5311) property 'NAC' of null error pop up when right click on complex dmn file
by xiaodong zhang (Jira)
xiaodong zhang created DROOLS-5311:
--------------------------------------
Summary: property 'NAC' of null error pop up when right click on complex dmn file
Key: DROOLS-5311
URL: https://issues.redhat.com/browse/DROOLS-5311
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.34.0.Final
Reporter: xiaodong zhang
Assignee: Guilherme Gomes
Attachments: WX20200510-174258(a)2x.png, demo.dmn
I have a complex dmn file, there are decision tables in context valule (see demo.dmn) ,try to right click and add columns on ContextEntry-17,ContextEntry-18,ContextEntry-19 alternatly,two or three times. You will see the popup error.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5310) java.lang.NoSuchMethodError: org.drools.core.common.ProjectClassLoader.storeClasses
by Balasubramanyam Nandula (Jira)
Balasubramanyam Nandula created DROOLS-5310:
-----------------------------------------------
Summary: java.lang.NoSuchMethodError: org.drools.core.common.ProjectClassLoader.storeClasses
Key: DROOLS-5310
URL: https://issues.redhat.com/browse/DROOLS-5310
Project: Drools
Issue Type: Bug
Reporter: Balasubramanyam Nandula
Assignee: Mario Fusco
SAP Hybris Platform Version: 6.4.0.7 | RHDM7.4 Libraries used as client for Rules Rest API
JDK Version used in Hybris - 1.8
When integrating RHDM7.4 libraries for SAP Hybris e-commerce solution we got the following exception on server start up. Libraries modified are provided in step to reproduce section
*+Runtime Server reported issue+*
(...) INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | ERROR [BatchSelfHealingItemsRunner] [PoolableThread] Problems executing de.hybris.platform.directpersistence.selfhealing.impl.DefaultSelfHealingService$BatchSelfHealingItemsScheduledRunnable@6cf2a843 : org.drools.core.common.ProjectClassLoader.storeClasses(Ljava/util/Map;)V
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | java.lang.NoSuchMethodError: org.drools.core.common.ProjectClassLoader.storeClasses(Ljava/util/Map;)V
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at org.drools.compiler.kie.builder.impl.KieModuleKieProject.init(KieModuleKieProject.java:66)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:269)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:238)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:187)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.init.impl.DefaultRuleEngineKieModuleSwapper.createKieModule(DefaultRuleEngineKieModuleSwapper.java:279)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.init.impl.DefaultRuleEngineBootstrap.startup(DefaultRuleEngineBootstrap.java:73)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.event.OnTenantStartupProcessor.lambda$1(OnTenantStartupProcessor.java:111)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at java.util.ArrayList.forEach(ArrayList.java:1257)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.event.OnTenantStartupProcessor.activateRulesModules(OnTenantStartupProcessor.java:111)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.event.OnTenantStartupProcessor.processOnTenantStartup(OnTenantStartupProcessor.java:79)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.ruleengine.event.OnTenantStartupProcessor$DefaultRuleEngineTenantListener.afterTenantStartUp(OnTenantStartupProcessor.java:276)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.AbstractTenant.lambda$0(AbstractTenant.java:912)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.ClassLoaderUtils.executeWithWebClassLoaderParentIfNeeded(ClassLoaderUtils.java:34)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.AbstractTenant.executeStartupNotifyIfNecessary(AbstractTenant.java:898)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.AbstractTenant.executeInitsIfNecessary(AbstractTenant.java:1390)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.Registry.assureTenantStarted(Registry.java:667)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.Registry.activateTenant(Registry.java:708)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.Registry.setCurrentTenant(Registry.java:555)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.Registry.activateMasterTenant(Registry.java:615)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.Registry.activateMasterTenantAndFailIfAlreadySet(Registry.java:603)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.util.threadpool.ThreadPool.setTenant(ThreadPool.java:79)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.util.threadpool.PoolableThread.internalRun(PoolableThread.java:206)
INFO | jvm 1 | main | 2020/05/09 22:21:47.953 | at de.hybris.platform.core.threadregistry.RegistrableThread.run(RegistrableThread.java:135)
(...)"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Steve Davidson edited comment on DROOLS-5106 at 5/8/20 8:13 PM:
----------------------------------------------------------------
Do you have an artifact for this in your local repo? I'm also using a proxied repo with artifact, and running into the same issue. Note that the artifact in question is NOT in the main repos -- and probably won't be. It will only be in local repos.
Should have added, Kie is what's not downloading the updates. Item is in local repo, but Kie is apparently ignoring the configured local repos with current version and going for the main repo's which don't have the object.
was (Author: northgorky):
Do you have an artifact for this in your local repo? I'm also using a proxied repo with artifact, and running into the same issue. Note that the artifact in question is NOT in the main repos -- and probably won't be. It will only be in local repos.
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Luca Molteni
> Priority: Major
> Labels: Drools, drools-compiler, maven
> Attachments: settings.xml
>
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5021) ClassCastException thrown when deserializing components of a Generic command
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5021?page=com.atlassian.jira.plug... ]
Steve Davidson commented on DROOLS-5021:
----------------------------------------
Created pull request https://github.com/kiegroup/droolsjbpm-integration/pull/2083. I wasn't able to figure out what the difference in setup/config between the Unit/Integration tests and Runtime was, so wasn't able to set up a Unit or Integration test to prove the issue/fix.
My push seems to have picked up commit 8d5736c (d5736c204173d8f30295f37235060a67cf6eaeb), which was the version number change from 7.29.0-SNAPSHOT to 7.29.0.Final -- not sure how much of an issue this is going to be.
The actual files changed were in commit [67f28c3 (67f28c39b1bbabde4318e15f687833a674f2e01a)]|https://github.com/kiegroup/dr...
> ClassCastException thrown when deserializing components of a Generic command
> ----------------------------------------------------------------------------
>
> Key: DROOLS-5021
> URL: https://issues.redhat.com/browse/DROOLS-5021
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.29.0.Final, 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Maciej Swiderski
> Priority: Major
> Attachments: DroolsKieContainerCommandServiceImplLine60.png, JSONMarshallerLine328.WrongSelected.png, KieIssueDemo.tbz, KieIssueDemo.tbz, KieRun.log
>
>
> When attempting to send a Generic Data object in an Insert Command to be added to the Rule Agenda, the server fails to deserialize the Insert Command with the following;
> Feb 6 11:09:30 thor jetty[21143]: Feb 06, 2020 11:09:30 AM org.kie.server.services.drools.DroolsKieContainerCommandServiceImpl callContainer
> Feb 6 11:09:30 thor jetty[21143]: SEVERE: Error calling container 'JUnit Test: kie-server'
> Feb 6 11:09:30 thor jetty[21143]: java.lang.ClassCastException: class java.util.LinkedHashMap cannot be cast to class org.kie.api.command.Command (java.util.LinkedHashMap is in module java.base of loader 'bootstrap'; org.kie.api.command.Command is in unnamed module of loader org.eclipse.jetty.webapp.WebAppClassLoader @51bd8b5c)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.kie.server.services.drools.DroolsKieContainerCommandServiceImpl.callContainer(DroolsKieContainerCommandServiceImpl.java:60)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:91)
> Feb 6 11:09:30 thor jetty[21143]: #011at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Feb 6 11:09:30 thor jetty[21143]: #011at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Feb 6 11:09:30 thor jetty[21143]: #011at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Feb 6 11:09:30 thor jetty[21143]: #011at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> Feb 6 11:09:30 thor jetty[21143]: #011at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.Server.handle(Server.java:500)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> Feb 6 11:09:30 thor jetty[21143]: #011at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> Feb 6 11:09:30 thor jetty[21143]: #011at java.base/java.lang.Thread.run(Thread.java:834)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months