[JBoss JIRA] (WFLY-11609) ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11609?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11609:
------------------------------------
Priority: Major (was: Trivial)
> ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11609
> URL: https://issues.jboss.org/browse/WFLY-11609
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Priority: Major
>
> There is the following configuration element
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <entity-bean>
> <optimistic-locking enabled="false"/>
> <bean-instance-pool pool-name="aPool"/>
> </entity-bean>
> for the ejb3 subsystem, this seems related to EJB2 EntityBeans which are removed from the container.
> This settings does not have any affect for the current JPA (EJB3) implementation and the EJB2 implementation is removed completely.
> It looks like that only the handler to read, write and manipulate the configuration are still there.
> So the element should be removed from the schema and code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11609) ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11609?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-11609:
---------------------------------------
Issue Type: Task (was: Bug)
Assignee: (was: Jason Greene)
The attributes involved here are indeed supported in the EAP 6.4 management API. They may even have some true runtime impact. They do affect an MSC service but I haven't looked closely enough to check whether that service does anything meaningful or is just cruft.
Still, the attributes exist and that means for compatibility we have to handle them.
I won't just resolve this as a "Not a Bug" though, as this can serve as a reminder to clean this up if we get to a version where we don't care about supporting a legacy HC that uses this. I'll make it a Task though as the current use of these attributes is not a bug.
> ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11609
> URL: https://issues.jboss.org/browse/WFLY-11609
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Priority: Trivial
>
> There is the following configuration element
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <entity-bean>
> <optimistic-locking enabled="false"/>
> <bean-instance-pool pool-name="aPool"/>
> </entity-bean>
> for the ejb3 subsystem, this seems related to EJB2 EntityBeans which are removed from the container.
> This settings does not have any affect for the current JPA (EJB3) implementation and the EJB2 implementation is removed completely.
> It looks like that only the handler to read, write and manipulate the configuration are still there.
> So the element should be removed from the schema and code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11609) ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11609?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11609:
-----------------------------------------
If this configuration was used in an EAP 6.4 server it needs to be retained, since a current domain mode domain controller must be able to manage EAP 6.4 slaves.
> ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11609
> URL: https://issues.jboss.org/browse/WFLY-11609
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Priority: Trivial
>
> There is the following configuration element
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <entity-bean>
> <optimistic-locking enabled="false"/>
> <bean-instance-pool pool-name="aPool"/>
> </entity-bean>
> for the ejb3 subsystem, this seems related to EJB2 EntityBeans which are removed from the container.
> This settings does not have any affect for the current JPA (EJB3) implementation and the EJB2 implementation is removed completely.
> It looks like that only the handler to read, write and manipulate the configuration are still there.
> So the element should be removed from the schema and code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11609) ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11609?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11609:
------------------------------------
Component/s: (was: Server)
> ejb3 subsystem configuration for element <entity-bean> will not have any effect and should be removed
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11609
> URL: https://issues.jboss.org/browse/WFLY-11609
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Priority: Trivial
>
> There is the following configuration element
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <entity-bean>
> <optimistic-locking enabled="false"/>
> <bean-instance-pool pool-name="aPool"/>
> </entity-bean>
> for the ejb3 subsystem, this seems related to EJB2 EntityBeans which are removed from the container.
> This settings does not have any affect for the current JPA (EJB3) implementation and the EJB2 implementation is removed completely.
> It looks like that only the handler to read, write and manipulate the configuration are still there.
> So the element should be removed from the schema and code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-10542) Log thread information of uncompleted EJB timer task
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10542?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10542:
------------------------------------
Issue Type: Enhancement (was: Feature Request)
> Log thread information of uncompleted EJB timer task
> -----------------------------------------------------
>
> Key: WFLY-10542
> URL: https://issues.jboss.org/browse/WFLY-10542
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
>
> {quote}WFLYEJB0043: A previous execution of timer [id=f3b0dfdb-1e94-46be-9964-69ff376fa6c0 timedObjectId=prbz-overview.prbz-overview.Aider auto-timer?:true persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2f5b46cf initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Thu May 31 00:00:00 SGT 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Thu May 31 00:00:00 SGT 2018.{quote}
> Warning message {{WFLYEJB0043}} indicates that the recurring timer is running longer than the interval, new timer is postponed. Because one App timer task worker thread is stuck there due to network connection failure.
> If the message logs more information about running threads of current timer task beyond timer id, it would be helpful to know which thread block the timer task and to allow forcibly interrupt it which is running longer than interval.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11614) IIOP: bug in SSL component creation
by Tomasz Adamski (Jira)
Tomasz Adamski created WFLY-11614:
-------------------------------------
Summary: IIOP: bug in SSL component creation
Key: WFLY-11614
URL: https://issues.jboss.org/browse/WFLY-11614
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 15.0.1.Final
Reporter: Tomasz Adamski
Assignee: Tomasz Adamski
Fix For: 16.0.0.Beta1
SSL component's target_requires and target_supports are switched over in the code which results in various errors in IIOP invocations between servers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3535) Out of Memory Error when creating KieSession
by Sarvagya Pant (Jira)
Sarvagya Pant created DROOLS-3535:
-------------------------------------
Summary: Out of Memory Error when creating KieSession
Key: DROOLS-3535
URL: https://issues.jboss.org/browse/DROOLS-3535
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.11.0.Final
Environment: In MacBook Pro (15-inch, 2017)
JDK 8
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
OpenJDK 11
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
Reporter: Sarvagya Pant
Assignee: Mario Fusco
We are using Drools compiler to compile DRL and create KieSession. Internally, when we try to compile large number of Spreadsheet (e.g. say 500), each containing about 30 rules, we get Out of memory error as shown in logs below:
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
at java.base/java.lang.Thread.start0(Native Method)
at java.base/java.lang.Thread.start(Thread.java:803)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1155)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1135)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:973)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2554)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2489)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:113)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:103)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:251)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:184)
at org.kie.internal.utils.KieHelper.verify(KieHelper.java:94)
at abc.xyz.KnowledgeBaseCreator.createKnowledgeBaseFromDrl(KnowledgeBaseCreator.java:319)
This issue can be traced to KnowledgeBuilderImpl.java as shown below:
Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>();
ForkJoinPool pool = new ForkJoinPool(); // avoid common pool
try {
pool.submit(() ->
rules.stream().parallel()
.filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName()))
.forEach(ruleDescr -> {
initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
ruleCxts.put(ruleDescr.getName(), context);
List<? extends KnowledgeBuilderResult> results = addRule(context);
if (!results.isEmpty()) {
synchronized (this.results) {
this.results.addAll(results);
}
}
})
).get();
} catch (InterruptedException | ExecutionException e) {
throw new RuntimeException("Rules compilation failed or interrupted", e);
}
for (RuleDescr ruleDescr : rules) {
RuleBuildContext context = ruleCxts.get(ruleDescr.getName());
if (context != null) {
pkgRegistry.getPackage().addRule(context.getRule());
}
}
Here ForkJoinPool is created without specifying any parallelism limit as well as without shutting it down. Moreover, since its avoiding common pool, anyone who is using it in a loop will face the issue as shown below.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3535) Out of Memory Error when creating KieSession
by Sarvagya Pant (Jira)
[ https://issues.jboss.org/browse/DROOLS-3535?page=com.atlassian.jira.plugi... ]
Sarvagya Pant updated DROOLS-3535:
----------------------------------
Description:
We are using Drools compiler to compile DRL and create KieSession. Internally, when we try to compile large number of Spreadsheet (e.g. say 500), each containing about 30 rules, we get Out of memory error as shown in logs below:
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
at java.base/java.lang.Thread.start0(Native Method)
at java.base/java.lang.Thread.start(Thread.java:803)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1155)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1135)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:973)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2554)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2489)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:113)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:103)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:251)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:184)
at org.kie.internal.utils.KieHelper.verify(KieHelper.java:94)
at abc.xyz.KnowledgeBaseCreator.createKnowledgeBaseFromDrl(KnowledgeBaseCreator.java:319)
This issue can be traced to KnowledgeBuilderImpl.java as shown below:
Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>();
ForkJoinPool pool = new ForkJoinPool(); // avoid common pool
try {
pool.submit(() ->
rules.stream().parallel()
.filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName()))
.forEach(ruleDescr -> {
initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
ruleCxts.put(ruleDescr.getName(), context);
List<? extends KnowledgeBuilderResult> results = addRule(context);
if (!results.isEmpty()) {
synchronized (this.results) {
this.results.addAll(results);
}
}
})
).get();
} catch (InterruptedException | ExecutionException e) {
throw new RuntimeException("Rules compilation failed or interrupted", e);
}
for (RuleDescr ruleDescr : rules) {
RuleBuildContext context = ruleCxts.get(ruleDescr.getName());
if (context != null) {
pkgRegistry.getPackage().addRule(context.getRule());
}
}
Here ForkJoinPool is created without specifying any parallelism limit as well as without shutting it down. Moreover, since its avoiding common pool, anyone who is using it in a loop will face the issue as discussed above.
was:
We are using Drools compiler to compile DRL and create KieSession. Internally, when we try to compile large number of Spreadsheet (e.g. say 500), each containing about 30 rules, we get Out of memory error as shown in logs below:
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
at java.base/java.lang.Thread.start0(Native Method)
at java.base/java.lang.Thread.start(Thread.java:803)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1155)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1135)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:973)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2554)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2489)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:113)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:103)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:251)
at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:184)
at org.kie.internal.utils.KieHelper.verify(KieHelper.java:94)
at abc.xyz.KnowledgeBaseCreator.createKnowledgeBaseFromDrl(KnowledgeBaseCreator.java:319)
This issue can be traced to KnowledgeBuilderImpl.java as shown below:
Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>();
ForkJoinPool pool = new ForkJoinPool(); // avoid common pool
try {
pool.submit(() ->
rules.stream().parallel()
.filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName()))
.forEach(ruleDescr -> {
initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
ruleCxts.put(ruleDescr.getName(), context);
List<? extends KnowledgeBuilderResult> results = addRule(context);
if (!results.isEmpty()) {
synchronized (this.results) {
this.results.addAll(results);
}
}
})
).get();
} catch (InterruptedException | ExecutionException e) {
throw new RuntimeException("Rules compilation failed or interrupted", e);
}
for (RuleDescr ruleDescr : rules) {
RuleBuildContext context = ruleCxts.get(ruleDescr.getName());
if (context != null) {
pkgRegistry.getPackage().addRule(context.getRule());
}
}
Here ForkJoinPool is created without specifying any parallelism limit as well as without shutting it down. Moreover, since its avoiding common pool, anyone who is using it in a loop will face the issue as shown below.
> Out of Memory Error when creating KieSession
> --------------------------------------------
>
> Key: DROOLS-3535
> URL: https://issues.jboss.org/browse/DROOLS-3535
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.11.0.Final
> Environment: In MacBook Pro (15-inch, 2017)
> JDK 8
> java version "1.8.0_161"
> Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
> OpenJDK 11
> openjdk version "11.0.1" 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
> Reporter: Sarvagya Pant
> Assignee: Mario Fusco
> Priority: Blocker
>
> We are using Drools compiler to compile DRL and create KieSession. Internally, when we try to compile large number of Spreadsheet (e.g. say 500), each containing about 30 rules, we get Out of memory error as shown in logs below:
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:803)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1155)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1135)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:973)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2554)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2489)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:113)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:103)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:251)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:184)
> at org.kie.internal.utils.KieHelper.verify(KieHelper.java:94)
> at abc.xyz.KnowledgeBaseCreator.createKnowledgeBaseFromDrl(KnowledgeBaseCreator.java:319)
> This issue can be traced to KnowledgeBuilderImpl.java as shown below:
> Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>();
> ForkJoinPool pool = new ForkJoinPool(); // avoid common pool
> try {
> pool.submit(() ->
> rules.stream().parallel()
> .filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName()))
> .forEach(ruleDescr -> {
> initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
> RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
> ruleCxts.put(ruleDescr.getName(), context);
> List<? extends KnowledgeBuilderResult> results = addRule(context);
> if (!results.isEmpty()) {
> synchronized (this.results) {
> this.results.addAll(results);
> }
> }
> })
> ).get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException("Rules compilation failed or interrupted", e);
> }
> for (RuleDescr ruleDescr : rules) {
> RuleBuildContext context = ruleCxts.get(ruleDescr.getName());
> if (context != null) {
> pkgRegistry.getPackage().addRule(context.getRule());
> }
> }
> Here ForkJoinPool is created without specifying any parallelism limit as well as without shutting it down. Moreover, since its avoiding common pool, anyone who is using it in a loop will face the issue as discussed above.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months