[JBoss JIRA] (DROOLS-1194) Creating KieSession from KieContainer fails on Google App Engine
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-1194:
------------------------------------
Summary: Creating KieSession from KieContainer fails on Google App Engine
Key: DROOLS-1194
URL: https://issues.jboss.org/browse/DROOLS-1194
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Environment: Drools 6.4.0.Final, Google App Engine
Reporter: Duncan Doyle
Assignee: Mario Fusco
Creating a KieSession from a KieContainer fails on Google App Engine. See stacktrace:
{code}
[INFO] java.lang.NoClassDefFoundError: javax.naming.InitialContext is a restricted class. Please see the Google App Engine developer's guide for more details.
[INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:52)
[INFO] at org.drools.compiler.kie.util.CDIHelper$BeanCreatorHolder.lookupBeanManager(CDIHelper.java:147)
[INFO] at org.drools.compiler.kie.util.CDIHelper$BeanCreatorHolder.loadBeanCreator(CDIHelper.java:140)
[INFO] at org.drools.compiler.kie.util.CDIHelper$BeanCreatorHolder.<clinit>(CDIHelper.java:137)
[INFO] at java.lang.Class.forName0(Native Method)
[INFO] at java.lang.Class.forName(Class.java:195)
[INFO] at com.google.appengine.tools.development.agent.runtime.RuntimeHelper.checkRestricted(RuntimeHelper.java:70)
[INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.checkRestricted(Runtime.java:65)
[INFO] at org.drools.compiler.kie.util.CDIHelper.wireListnersAndWIHs(CDIHelper.java:45)
[INFO] at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:621)
[INFO] at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:585)
[INFO] at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:113)
[INFO] at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.resetKieSession(DroolsScoreDirector.java:68)
[INFO] at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.setWorkingSolution(DroolsScoreDirector.java:61)
[INFO] at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.setWorkingSolutionFromBestSolution(DefaultSolverScope.java:198)
[INFO] at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:196)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/26/16 4:24 AM:
---------------------------------------------------------
OneWayTcp shows a latency of ~2 us! Increasing the payload from 9 bytes to (e.g.) 2000 reduces the latency even further to below 1 us!
This is weird as in {{RoundTripTcp}} (the round trip version of {{OneWayTcp}}), round trip times are ~50 us; I'd expect ~2-4 us (2x latency)...
was (Author: belaban):
OneWayTcp shows a latency of ~2 us! Increasing the payload from 9 bytes to (e.g.) 2000 reduces the latency even further to below 1 us!
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2065 at 5/26/16 3:41 AM:
---------------------------------------------------------
OneWayTcp shows a latency of ~2 us! Increasing the payload from 9 bytes to (e.g.) 2000 reduces the latency even further to below 1 us!
was (Author: belaban):
OneWayTcp shows a latency of ~2 us!
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2065:
--------------------------------
OneWayTcp shows a latency of ~2 us!
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6630) "default" as default name for long-running-threads and short-running-threads leads to thread groups with the same name default-threads
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6630?page=com.atlassian.jira.plugin.... ]
Chao Wang updated WFLY-6630:
----------------------------
Attachment: WFLY-6630.patch
The tricky part is that the "default" is also part of service name as added inside [WorkManagerAdd.java|https://github.com/wildfly/wildfly/blob/9de9217e0106d...]
{code:java}
builder.addDependency(ServiceBuilder.DependencyType.OPTIONAL, ThreadsServices.EXECUTOR.append(WORKMANAGER_LONG_RUNNING).append(name), Executor.class, wmService.getExecutorLongInjector());
builder.addDependency(ThreadsServices.EXECUTOR.append(WORKMANAGER_SHORT_RUNNING).append(name), Executor.class, wmService.getExecutorShortInjector());
{code}
and [DistributedWorkManagerAdd.java|https://github.com/wildfly/wildfly/blob/9d...]
{code:java}
builder.addDependency(ServiceBuilder.DependencyType.OPTIONAL, ThreadsServices.EXECUTOR.append(WORKMANAGER_LONG_RUNNING).append(name), Executor.class, wmService.getExecutorLongInjector());
builder.addDependency(ThreadsServices.EXECUTOR.append(WORKMANAGER_SHORT_RUNNING).append(name), Executor.class, wmService.getExecutorShortInjector());
{code}
here, the value of {{name}} is "default" based on default workmanager's name. When I made changes as attached file for default-short-running-threads and default-long-running-threads. The services name are also changed. Which broke a MixedDomainDeployment700TestCase due to "One or more services were unable to start due to one or more indirect dependencies not being available". I have tried to use transformer, but it does not help for these service name change.
> "default" as default name for long-running-threads and short-running-threads leads to thread groups with the same name default-threads
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6630
> URL: https://issues.jboss.org/browse/WFLY-6630
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 10.0.0.Final
> Reporter: Martin Simka
> Assignee: Chao Wang
> Priority: Minor
> Attachments: WFLY-6630.patch
>
>
> /subsystem=jca/workmanager=default/short-running-threads=default
> /subsystem=jca/workmanager=default/long-running-threads=default
> Thread group with name {{default-threads}} is created for both of these addresses. It's because thread group name is created from last element of resource's address + string {{-threads}}.
> [ThreadPoolManagementUtils.java#L166|https://github.com/wildfly/wildfly-co...]
> {code:java}
> params.name = pathAddress.getLastElement().getValue();
> {code}
> [ThreadFactoryResolver.java#L149|https://github.com/wildfly/wildfly-core/b...]
> {code:java}
> protected String getThreadGroupName(String threadPoolName) {
> return threadPoolName + "-threads";
> }
> {code}
> Thread groups for different resources shouldn't have the same name. Also such a general name {{default-threads}} could be confusing when debugging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (WFLY-6653) The default min and max pool size of -1 is confusing.
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6653?page=com.atlassian.jira.plugin.... ]
Chen Maoqian moved JBEAP-4723 to WFLY-6653:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6653 (was: JBEAP-4723)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
> The default min and max pool size of -1 is confusing.
> ------------------------------------------------------
>
> Key: WFLY-6653
> URL: https://issues.jboss.org/browse/WFLY-6653
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Environment: JBoss EAP 7.0.0.
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
>
> The default values for min and max pool size are confusing
> "max-pool-size" => -1,
> "min-pool-size" => -1,
> They should either say default
> "max-pool-size" => default,
> "min-pool-size" => default,
> or display the default JCA values which I believe are 2 and 20
> "max-pool-size" => 20,
> "min-pool-size" => 2,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (DROOLS-1193) MemoryUtil's static constructor call to ManagementFactory.getMemoryPoolMXBeans() fails on Google App Engine
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1193?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1193:
-------------------------------------
Affects Version/s: 6.4.0.Final
> MemoryUtil's static constructor call to ManagementFactory.getMemoryPoolMXBeans() fails on Google App Engine
> -----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1193
> URL: https://issues.jboss.org/browse/DROOLS-1193
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> {code}
> [INFO] java.lang.NoClassDefFoundError: java.lang.management.ManagementFactory is a restricted class. Please see the Google App Engine developer's guide for more details.
> [INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:52)
> [INFO] at org.drools.core.util.MemoryUtil.<clinit>(MemoryUtil.java:33)
> [INFO] at java.lang.Class.forName0(Native Method)
> [INFO] at java.lang.Class.forName(Class.java:195)
> [INFO] at com.google.appengine.tools.development.agent.runtime.RuntimeHelper.checkRestricted(RuntimeHelper.java:70)
> [INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.checkRestricted(Runtime.java:65)
> [INFO] at org.drools.core.RuleBaseConfiguration.setPermGenThreshold(RuleBaseConfiguration.java:583)
> [INFO] at org.drools.core.RuleBaseConfiguration.init(RuleBaseConfiguration.java:451)
> [INFO] at org.drools.core.RuleBaseConfiguration.init(RuleBaseConfiguration.java:429)
> [INFO] at org.drools.core.RuleBaseConfiguration.<init>(RuleBaseConfiguration.java:278)
> [INFO] at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieBaseConfiguration(KieServicesImpl.java:185)
> {code}
> the problem is in this code:
> {code}
> static {
> if (!hasPermGen() || ClassUtils.isAndroid()) { // hasPermGen is true because GAE doesn't support java 8 yet
> permGenStats = new DummyMemoryStats();
> } else {
> MemoryPoolMXBean permGenBean = null;
> for (MemoryPoolMXBean mx : ManagementFactory.getMemoryPoolMXBeans()) { // <=== EXCEPTION
> if (mx.getName() != null && mx.getName().contains("Perm")) {
> permGenBean = mx;
> break;
> }
> }
> permGenStats = new MBeanMemoryStats(permGenBean);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (DROOLS-1193) MemoryUtil's static constructor call to ManagementFactory.getMemoryPoolMXBeans() fails on Google App Engine
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1193:
----------------------------------------
Summary: MemoryUtil's static constructor call to ManagementFactory.getMemoryPoolMXBeans() fails on Google App Engine
Key: DROOLS-1193
URL: https://issues.jboss.org/browse/DROOLS-1193
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
{code}
[INFO] java.lang.NoClassDefFoundError: java.lang.management.ManagementFactory is a restricted class. Please see the Google App Engine developer's guide for more details.
[INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:52)
[INFO] at org.drools.core.util.MemoryUtil.<clinit>(MemoryUtil.java:33)
[INFO] at java.lang.Class.forName0(Native Method)
[INFO] at java.lang.Class.forName(Class.java:195)
[INFO] at com.google.appengine.tools.development.agent.runtime.RuntimeHelper.checkRestricted(RuntimeHelper.java:70)
[INFO] at com.google.appengine.tools.development.agent.runtime.Runtime.checkRestricted(Runtime.java:65)
[INFO] at org.drools.core.RuleBaseConfiguration.setPermGenThreshold(RuleBaseConfiguration.java:583)
[INFO] at org.drools.core.RuleBaseConfiguration.init(RuleBaseConfiguration.java:451)
[INFO] at org.drools.core.RuleBaseConfiguration.init(RuleBaseConfiguration.java:429)
[INFO] at org.drools.core.RuleBaseConfiguration.<init>(RuleBaseConfiguration.java:278)
[INFO] at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieBaseConfiguration(KieServicesImpl.java:185)
{code}
the problem is in this code:
{code}
static {
if (!hasPermGen() || ClassUtils.isAndroid()) { // hasPermGen is true because GAE doesn't support java 8 yet
permGenStats = new DummyMemoryStats();
} else {
MemoryPoolMXBean permGenBean = null;
for (MemoryPoolMXBean mx : ManagementFactory.getMemoryPoolMXBeans()) { // <=== EXCEPTION
if (mx.getName() != null && mx.getName().contains("Perm")) {
permGenBean = mx;
break;
}
}
permGenStats = new MBeanMemoryStats(permGenBean);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months