[JBoss JIRA] (DROOLS-5308) Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5308?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5308:
-------------------------------
Affects Version/s: 7.37.0.Final
(was: 7.36.0.Final)
> Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5308
> URL: https://issues.redhat.com/browse/DROOLS-5308
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Affects Versions: 7.37.0.Final
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tooling
> Fix For: 7.38.0.Final
>
>
> When we run scenarios for rules with name longer than 27 characters and click on the Coverage Report. We can’t read the number of times the rule ran because the rule name overlaps it, even if I expand the frame. Take a look at the attached screenshot.
> Expected Result: The numbers should always be visible no matter how long the name or how narrow/wide the frame is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5308) Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5308?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5308:
-------------------------------
Fix Version/s: 7.38.0.Final
(was: 7.37.0.Final)
> Not able to read number of times rule fire in Scenario Coverage Report if rule name is longer than 27 characters
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5308
> URL: https://issues.redhat.com/browse/DROOLS-5308
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Affects Versions: 7.36.0.Final
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tooling
> Fix For: 7.38.0.Final
>
>
> When we run scenarios for rules with name longer than 27 characters and click on the Coverage Report. We can’t read the number of times the rule ran because the rule name overlaps it, even if I expand the frame. Take a look at the attached screenshot.
> Expected Result: The numbers should always be visible no matter how long the name or how narrow/wide the frame is.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5251) Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5251?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5251:
--------------------------------
Labels: drools-tools (was: )
> Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5251
> URL: https://issues.redhat.com/browse/DROOLS-5251
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Tracy Hires
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
> Attachments: Decision.dmn, actual rendering.png, expected rendering.png
>
>
> When the result of a Business Knowledge Model is a structure, and the logical expression for the business knowledge model is a decision table, the column headers for the output do not render correctly (see attached actual rendering.png, expected rendering.png). If the Decision Table in the BKM is nested inside of a context, then the headers will render correctly. (Though doing this will trigger the behavior described in DROOLS-5236.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5251) Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5251?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5251:
--------------------------------
Tester: Jozef Marko
> Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5251
> URL: https://issues.redhat.com/browse/DROOLS-5251
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Tracy Hires
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
> Attachments: Decision.dmn, actual rendering.png, expected rendering.png
>
>
> When the result of a Business Knowledge Model is a structure, and the logical expression for the business knowledge model is a decision table, the column headers for the output do not render correctly (see attached actual rendering.png, expected rendering.png). If the Decision Table in the BKM is nested inside of a context, then the headers will render correctly. (Though doing this will trigger the behavior described in DROOLS-5236.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5326) Make LambdaIntrospector.methodFingerprintsMap cache size configurable
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5326?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5326:
--------------------------------------
Summary: Make LambdaIntrospector.methodFingerprintsMap cache size configurable (was: Make DynamicProjectClassLoader$DefaultInternalTypesClassLoader cache size configurable)
> Make LambdaIntrospector.methodFingerprintsMap cache size configurable
> ---------------------------------------------------------------------
>
> Key: DROOLS-5326
> URL: https://issues.redhat.com/browse/DROOLS-5326
> Project: Drools
> Issue Type: Task
> Components: executable model
> Affects Versions: 7.37.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
>
> Using the executable model, we can see a memory retention in LambdaIntrospector after reloading the kbase multiple times:
> {noformat}
> Class Name | Shallow Heap | Retained Heap
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62e90a8 | 56 | 1,243,424
> |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62c2158 | 0 | 0
> |- head java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> |- table java.util.HashMap$Node[64] @ 0xd7283140 | 272 | 272
> | |- <class> class java.util.HashMap$Node[] @ 0xc02d3af8 | 0 | 0
> | |- [49] java.util.LinkedHashMap$Entry @ 0xc6336bf0 | 40 | 44,472
> | |- [46] java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> | |- [30] java.util.LinkedHashMap$Entry @ 0xcb4305f0 | 40 | 39,760
> | |- [35] java.util.LinkedHashMap$Entry @ 0xcb4415e0 | 40 | 23,320
> | |- [12] java.util.LinkedHashMap$Entry @ 0xcb446c08 | 40 | 22,104
> | |- [57] java.util.LinkedHashMap$Entry @ 0xcb44bd70 | 40 | 47,368
> | |- [24] java.util.LinkedHashMap$Entry @ 0xcb457f28 | 40 | 52,672
> | |- [63] java.util.LinkedHashMap$Entry @ 0xcb46a990 | 40 | 45,064
> | |- [14] java.util.LinkedHashMap$Entry @ 0xce1ccaf8 | 40 | 47,368
> | |- [45] java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | |- [54] java.util.LinkedHashMap$Entry @ 0xce1e41c0 | 40 | 23,320
> | | |- <class> class java.util.LinkedHashMap$Entry @ 0xc02c8090 System Class | 0 | 0
> | | |- after java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | | |- key org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xce1e41e8 | 24 | 280
> | | | |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xc62e01c0 | 0 | 0
> | | | |- classLoader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xcb643360 | 64 | 581,176
> | | | | |- <class> class org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xc24d3320| 8 | 32
> | | | | |- projectClassLoader org.drools.dynamic.DynamicProjectClassLoader @ 0xcb5ed8b8 | 88 | 45,501,888
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
> LambdaIntrospector$1 extends LinkedHashMap and its cache size is 32.
> https://github.com/kiegroup/drools/blob/master/drools-model/drools-model-...
> The intent of this JIRA is to provide a flag to make this cache size configurable.
--
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:
----------------------------------------
Additional info:
kie-server-7.29.0.Final-webc.war
Also, same behavior on:
{noformat}
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~18.04-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
{noformat}
> 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: Mario Fusco
> Priority: Major
> Attachments: DroolsKieContainerCommandServiceImplLine60.png, JSONMarshallerLine328.WrongSelected.png, KieIssueDemo-0.1.0-SNAPSHOT.jar, KieIssueDemo.tbz, KieIssueDemo.tbz, KieRun.log, start.ini
>
>
> 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
[JBoss JIRA] (DROOLS-5326) Make DynamicProjectClassLoader$DefaultInternalTypesClassLoader cache size configurable
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5326?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5326:
--------------------------------------
Story Points: 2
Sprint: 2020 Week 19-21 (from May 4)
> Make DynamicProjectClassLoader$DefaultInternalTypesClassLoader cache size configurable
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5326
> URL: https://issues.redhat.com/browse/DROOLS-5326
> Project: Drools
> Issue Type: Task
> Components: executable model
> Affects Versions: 7.37.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
>
> Using the executable model, we can see a memory retention in LambdaIntrospector after reloading the kbase multiple times:
> {noformat}
> Class Name | Shallow Heap | Retained Heap
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62e90a8 | 56 | 1,243,424
> |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62c2158 | 0 | 0
> |- head java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> |- table java.util.HashMap$Node[64] @ 0xd7283140 | 272 | 272
> | |- <class> class java.util.HashMap$Node[] @ 0xc02d3af8 | 0 | 0
> | |- [49] java.util.LinkedHashMap$Entry @ 0xc6336bf0 | 40 | 44,472
> | |- [46] java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> | |- [30] java.util.LinkedHashMap$Entry @ 0xcb4305f0 | 40 | 39,760
> | |- [35] java.util.LinkedHashMap$Entry @ 0xcb4415e0 | 40 | 23,320
> | |- [12] java.util.LinkedHashMap$Entry @ 0xcb446c08 | 40 | 22,104
> | |- [57] java.util.LinkedHashMap$Entry @ 0xcb44bd70 | 40 | 47,368
> | |- [24] java.util.LinkedHashMap$Entry @ 0xcb457f28 | 40 | 52,672
> | |- [63] java.util.LinkedHashMap$Entry @ 0xcb46a990 | 40 | 45,064
> | |- [14] java.util.LinkedHashMap$Entry @ 0xce1ccaf8 | 40 | 47,368
> | |- [45] java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | |- [54] java.util.LinkedHashMap$Entry @ 0xce1e41c0 | 40 | 23,320
> | | |- <class> class java.util.LinkedHashMap$Entry @ 0xc02c8090 System Class | 0 | 0
> | | |- after java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | | |- key org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xce1e41e8 | 24 | 280
> | | | |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xc62e01c0 | 0 | 0
> | | | |- classLoader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xcb643360 | 64 | 581,176
> | | | | |- <class> class org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xc24d3320| 8 | 32
> | | | | |- projectClassLoader org.drools.dynamic.DynamicProjectClassLoader @ 0xcb5ed8b8 | 88 | 45,501,888
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
> LambdaIntrospector$1 extends LinkedHashMap and its cache size is 32.
> https://github.com/kiegroup/drools/blob/master/drools-model/drools-model-...
> The intent of this JIRA is to provide a flag to make this cache size configurable.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5326) Make DynamicProjectClassLoader$DefaultInternalTypesClassLoader cache size configurable
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5326?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi moved RHDM-1342 to DROOLS-5326:
-------------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5326 (was: RHDM-1342)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: executable model
(was: BRE)
Affects Version/s: 7.37.0.Final
(was: 7.7.0.GA)
QE Status: NEW
> Make DynamicProjectClassLoader$DefaultInternalTypesClassLoader cache size configurable
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-5326
> URL: https://issues.redhat.com/browse/DROOLS-5326
> Project: Drools
> Issue Type: Task
> Components: executable model
> Affects Versions: 7.37.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: support
>
> Using the executable model, we can see a memory retention in LambdaIntrospector after reloading the kbase multiple times:
> {noformat}
> Class Name | Shallow Heap | Retained Heap
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62e90a8 | 56 | 1,243,424
> |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$1 @ 0xc62c2158 | 0 | 0
> |- head java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> |- table java.util.HashMap$Node[64] @ 0xd7283140 | 272 | 272
> | |- <class> class java.util.HashMap$Node[] @ 0xc02d3af8 | 0 | 0
> | |- [49] java.util.LinkedHashMap$Entry @ 0xc6336bf0 | 40 | 44,472
> | |- [46] java.util.LinkedHashMap$Entry @ 0xc63577e0 | 40 | 52,080
> | |- [30] java.util.LinkedHashMap$Entry @ 0xcb4305f0 | 40 | 39,760
> | |- [35] java.util.LinkedHashMap$Entry @ 0xcb4415e0 | 40 | 23,320
> | |- [12] java.util.LinkedHashMap$Entry @ 0xcb446c08 | 40 | 22,104
> | |- [57] java.util.LinkedHashMap$Entry @ 0xcb44bd70 | 40 | 47,368
> | |- [24] java.util.LinkedHashMap$Entry @ 0xcb457f28 | 40 | 52,672
> | |- [63] java.util.LinkedHashMap$Entry @ 0xcb46a990 | 40 | 45,064
> | |- [14] java.util.LinkedHashMap$Entry @ 0xce1ccaf8 | 40 | 47,368
> | |- [45] java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | |- [54] java.util.LinkedHashMap$Entry @ 0xce1e41c0 | 40 | 23,320
> | | |- <class> class java.util.LinkedHashMap$Entry @ 0xc02c8090 System Class | 0 | 0
> | | |- after java.util.LinkedHashMap$Entry @ 0xce1d8400 | 40 | 39,760
> | | |- key org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xce1e41e8 | 24 | 280
> | | | |- <class> class org.drools.modelcompiler.util.LambdaIntrospector$ClassIdentifier @ 0xc62e01c0 | 0 | 0
> | | | |- classLoader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xcb643360 | 64 | 581,176
> | | | | |- <class> class org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @ 0xc24d3320| 8 | 32
> | | | | |- projectClassLoader org.drools.dynamic.DynamicProjectClassLoader @ 0xcb5ed8b8 | 88 | 45,501,888
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
> LambdaIntrospector$1 extends LinkedHashMap and its cache size is 32.
> https://github.com/kiegroup/drools/blob/master/drools-model/drools-model-...
> The intent of this JIRA is to provide a flag to make this cache size configurable.
--
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 Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13444:
------------------------------------
Priority: Major (was: Blocker)
> 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: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, 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