[JBoss JIRA] (DROOLS-5021) ClassCastException thrown when deserializing components of a Generice command
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5021?page=com.atlassian.jira.plug... ]
Steve Davidson updated DROOLS-5021:
-----------------------------------
Attachment: DroolsKieContainerCommandServiceImplLine60.png
JSONMarshallerLine328.WrongSelected.png
> ClassCastException thrown when deserializing components of a Generice 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
> Reporter: Steve Davidson
> Assignee: Maciej Swiderski
> Priority: Major
> Attachments: DroolsKieContainerCommandServiceImplLine60.png, JSONMarshallerLine328.WrongSelected.png, 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, 5 months
[JBoss JIRA] (WFLY-5529) Clustering Quickstarts Tracker
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-5529?page=com.atlassian.jira.plugin... ]
Ranabir Chakraborty commented on WFLY-5529:
-------------------------------------------
[~rhusar] Can you please elaborate this issue ?
> Clustering Quickstarts Tracker
> ------------------------------
>
> Key: WFLY-5529
> URL: https://issues.redhat.com/browse/WFLY-5529
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster, Quickstarts
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: Awaiting Volunteers
>
>
> Tracker for clustering quickstarts.
> There are bunch of areas that could use a quickstart, see linked issues. Bunch of areas that might be interesting as well with no concrete plans:
> * Cross-site replication
> * JGroups channel injection (community-only)
> * Infinispan cache injection (community-only)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4967.
---------------------------------
Resolution: Explained
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls, CanNotDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4645) High memory consumption with JIT
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4645?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-4645.
---------------------------------
Resolution: Cannot Reproduce
> High memory consumption with JIT
> --------------------------------
>
> Key: DROOLS-4645
> URL: https://issues.redhat.com/browse/DROOLS-4645
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.29.0.Final
> Reporter: Radovan Synek
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: Screenshot from 2019-10-15 10-30-27.png, Screenshot from 2019-10-15 10-31-53.png
>
>
> Employee Rostering example for OptaPlanner shows excessive memory consumption, which is connected with Drools score calculation.
> Please see the reproducer - running it without drools JIT finishes on time with 3GB of memory while with drools JIT being active it fails due to "GC overhead limit exceeded" despite the fact it god twice as much memory.
> Logging (add -Dlogback.level.org.optaplanner=trace to the execute_jit.sh script) showed there is a huge pillar move changing ~hundreds of entities which takes seconds to calculate score. During this move's evaluation, the memory consumption increases to a point when GC takes over and later fails.
> Memory sampling and heap dump investigation showed there are ~10^7 objects of org.drools.core.reteoo.FromNodeLeftTuple class, taking more memory than any other data type in the VM.
> See the attached screenshots.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-4967:
-------------------------------------
[~acc_team] The xls you attached just has the wrong package and import. (Sorry I did the same mistake with mine). If you fix both you'll see that MultiKieBaseTest is passing as expected. In other words I still cannot reproduce the problem. Can you?
> decision table rules are not loaded into kiebase
> ------------------------------------------------
>
> Key: DROOLS-4967
> URL: https://issues.redhat.com/browse/DROOLS-4967
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final
> Reporter: Volodymyr Shymkiv
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: CanDrink2.xls, CanNotDrink2.xls
>
>
> When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration.
> According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name.
> The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows:
> # find "RuleSet" string in the binary data
> # find and return the nearest string which can act as a valid java package name
> The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell.
> To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell.
> Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46
> In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months