[JBoss JIRA] (WFLY-7691) Custom pool not working when applied to Message-Driven Bean
by Evandro Pomatti (JIRA)
[ https://issues.jboss.org/browse/WFLY-7691?page=com.atlassian.jira.plugin.... ]
Evandro Pomatti updated WFLY-7691:
----------------------------------
Steps to Reproduce:
1) Create a JMS Queue:
{noformat}
jms-queue add --queue-address=customQueue --entries=java:jboss/jms/customQueue
{noformat}
2) Create a custom pool with a max-pool-size greater than the default (let's use 50):
{panel:title=My title}
/subsystem=ejb3/strict-max-bean-instance-pool=customPool/:add(max-pool-size=50,timeout=5,timeout-unit=MINUTES)
{panel}
3) Create a WAR application with an MDB and assign the annotation @Pool("customPool") to the MDB and also @ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "50") to match the pool max size. Add a Thread.sleep to the onMessage() method to simulate.
@MessageDriven(name = "CustomMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "java:jboss/jms/customQueue"),
@ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "50") })
@Pool("customPool")
public class DummyListener implements MessageListener {
private static AtomicInteger count = new AtomicInteger();
@Override
public void onMessage(Message message) {
try {
System.out.println("Count: " + count.incrementAndGet());
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
@Pool annotation needs the following dependency:
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-ext-api</artifactId>
<version>2.2.0.Final</version>
<scope>provided</scope>
</dependency>
4) Deploy the application and send 50 messages to the queue.
@Stateless
@Path("/enqueue")
public class DummyResource {
@Inject
@JMSConnectionFactory("java:/JmsXA")
private JMSContext context;
@Resource(mappedName = "java:jboss/jms/customQueue")
private Queue customQueue;
@GET
public void get() {
IntStream.range(0, 50).forEach(i -> context.createProducer().send(customQueue, "message"));
}
}
Only 15 queue messages will be dequeue at a time, not the 50 that was specified in the pool.
I also don't know why 15, since the default MDB pool is configured to be 20.
was:
1) Create a JMS Queue:
jms-queue add --queue-address=customQueue --entries=java:jboss/jms/customQueue
2) Create a custom pool with a max-pool-size greater than the default (let's use 50):
/subsystem=ejb3/strict-max-bean-instance-pool=customPool/:add(max-pool-size=50,timeout=5,timeout-unit=MINUTES)
3) Create a WAR application with an MDB and assign the annotation @Pool("customPool") to the MDB and also @ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "50") to match the pool max size. Add a Thread.sleep to the onMessage() method to simulate.
@MessageDriven(name = "CustomMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "java:jboss/jms/customQueue"),
@ActivationConfigProperty(propertyName = "maxSessions", propertyValue = "50") })
@Pool("customPool")
public class DummyListener implements MessageListener {
private static AtomicInteger count = new AtomicInteger();
@Override
public void onMessage(Message message) {
try {
System.out.println("Count: " + count.incrementAndGet());
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
@Pool annotation needs the following dependency:
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-ext-api</artifactId>
<version>2.2.0.Final</version>
<scope>provided</scope>
</dependency>
4) Deploy the application and send 50 messages to the queue.
@Stateless
@Path("/enqueue")
public class DummyResource {
@Inject
@JMSConnectionFactory("java:/JmsXA")
private JMSContext context;
@Resource(mappedName = "java:jboss/jms/customQueue")
private Queue customQueue;
@GET
public void get() {
IntStream.range(0, 50).forEach(i -> context.createProducer().send(customQueue, "message"));
}
}
Only 15 queue messages will be dequeue at a time, not the 50 that was specified in the pool.
I also don't know why 15, since the default MDB pool is configured to be 20.
> Custom pool not working when applied to Message-Driven Bean
> -----------------------------------------------------------
>
> Key: WFLY-7691
> URL: https://issues.jboss.org/browse/WFLY-7691
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Evandro Pomatti
> Labels: mdb, pool
>
> I tried to configure a custom thread pool por an MDB in order to increase performance, but it seems that the association is being ignored by WildFly.
> When I associate my custom pool with increased size to 50 to my MDB, only 15 messages keep getting dequeue at a time.
> I also don't know why 15, since the default MDB pool "mdb-strict-max-pool" max size is configured to be 20.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7691) Custom pool not working when applied to Message-Driven Bean
by Evandro Pomatti (JIRA)
Evandro Pomatti created WFLY-7691:
-------------------------------------
Summary: Custom pool not working when applied to Message-Driven Bean
Key: WFLY-7691
URL: https://issues.jboss.org/browse/WFLY-7691
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Evandro Pomatti
I tried to configure a custom thread pool por an MDB in order to increase performance, but it seems that the association is being ignored by WildFly.
When I associate my custom pool with increased size to 50 to my MDB, only 15 messages keep getting dequeue at a time.
I also don't know why 15, since the default MDB pool "mdb-strict-max-pool" max size is configured to be 20.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2057) Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2057:
----------------------------------------
Summary: Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
Key: WFCORE-2057
URL: https://issues.jboss.org/browse/WFCORE-2057
Project: WildFly Core
Issue Type: Bug
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
The op should fail as the write is not allowed.
Test is currently only passing because the WFCORE-2053 problem is producing false positives.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1214) Operation headers not propagated to domain servers when 'composite' op is used
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1214?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1214:
------------------------------------------
The WFCORE-1214 fix causes WFCORE-2055 by dropping headers from steps in a composite op, resulting in the domain server not recognizing that a local write was initiated by the caller rather than by the HC.
> Operation headers not propagated to domain servers when 'composite' op is used
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1214
> URL: https://issues.jboss.org/browse/WFCORE-1214
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.4.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.5.CR1
>
>
> When the user adds request headers to an op, they are not propagated to the servers during domain rollout if the 'composite' op is involved.
> For example, if I add some stdout printing of what the headers are on the various processes and invoke this:
> {code}
> [domain@localhost:9990 /] deploy ~/tmp/helloworld.war --headers={blocking-timeout=5;rollback-on-runtime-failure=false} --all-server-groups
> {code}
> Then on a HC with two servers, this is logged:
> [Host Controller] 10:53:40,697 INFO [stdout] (management-handler-thread - 3) "composite" headers: {
> [Host Controller] 10:53:40,697 INFO [stdout] (management-handler-thread - 3) "blocking-timeout" => "5",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "rollback-on-runtime-failure" => "false",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "caller-type" => "user",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "access-mechanism" => "NATIVE"
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) }
> [Host Controller] 10:53:40,727 INFO [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-2.0.5.Final-SNAPSHOT/domain/data/content/6f/cd9eae343ed6d5aa9fffa83012d155b1ef911c/content
> [Server:server-one] 10:53:40,772 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: null
> [Server:server-two] 10:53:40,772 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: null
> The HC logs, then the servers report. The user-specified headers are not included.
> Invoke the same op without the batch and this is logged:
> {code}
> [Host Controller] 10:43:50,400 INFO [stdout] (management-handler-thread - 4) "composite" headers: {
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "blocking-timeout" => "5",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "rollback-on-runtime-failure" => "false",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "caller-type" => "user",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "access-mechanism" => "NATIVE"
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) }
> [Host Controller] 10:43:50,425 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-2.0.5.Final-SNAPSHOT/domain/data/content/6f/cd9eae343ed6d5aa9fffa83012d155b1ef911c/content
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: {
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "blocking-timeout" => "5",
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "rollback-on-runtime-failure" => "false",
> [Server:server-one] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: {
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "access-mechanism" => "NATIVE",
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "blocking-timeout" => "5",
> [Server:server-two] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "domain-uuid" => "216d2e99-dba5-4c89-8020-b0c16bd553c5"
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "rollback-on-runtime-failure" => "false",
> [Server:server-two] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) }
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "access-mechanism" => "NATIVE",
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "domain-uuid" => "216d2e99-dba5-4c89-8020-b0c16bd553c5"
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) }
> {code}
> Expected headers are present.
> Note the CLI 'deploy' is far from the only time the 'composite' op is used. Among other places, the high level CLI 'batch' command in a domain involves use of 'composite'.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2055) Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2055?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2055:
------------------------------------------
The WFCORE-1214 fix causes WFCORE-2055 by dropping headers from steps in a composite op, resulting in the domain server not recognizing that a local write was initiated by the caller rather than by the HC.
> Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2055
> URL: https://issues.jboss.org/browse/WFCORE-2055
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
> The op should fail as the write is not allowed.
> Test is currently only passing because the WFCORE-2053 problem is producing false positives.
> Problem is likely (but not certainly) due to changes made to OperationRouting as part of https://github.com/wildfly/wildfly-core/pull/597
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2055) Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2055?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2055:
-------------------------------------
Description:
Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
The op should fail as the write is not allowed.
Test is currently only passing because the WFCORE-2053 problem is producing false positives.
was:
Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
The op should fail as the write is not allowed.
Test is currently only passing because the WFCORE-2053 problem is producing false positives.
Problem is likely (but not certainly) due to changes made to OperationRouting as part of https://github.com/wildfly/wildfly-core/pull/597
> Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2055
> URL: https://issues.jboss.org/browse/WFCORE-2055
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
> The op should fail as the write is not allowed.
> Test is currently only passing because the WFCORE-2053 problem is producing false positives.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1373) Rules are not removed from the KieModule/KieContainer
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1373?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1373:
----------------------------------
Attachment: NotRemovingRules.java
> Rules are not removed from the KieModule/KieContainer
> -----------------------------------------------------
>
> Key: DROOLS-1373
> URL: https://issues.jboss.org/browse/DROOLS-1373
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: NotRemovingRules.java, drools-1373.PNG
>
>
> I have attached a reproducer named NotRemovingRules.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 2 rules and removes 2 rules and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the last .dmp file created names ckpoint3.drl you will see that rules named like
> org.drools.compiler.integraionTests.Rule_120#0DefaultConsequenceInvoker are still present. However, if you examine the console or System.out you will notice the code is executing that is removing the rules from the KieModule/KieContainer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1373) Rules are not removed from the KieModule/KieContainer
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1373?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1373:
----------------------------------
Attachment: drools-1373.PNG
> Rules are not removed from the KieModule/KieContainer
> -----------------------------------------------------
>
> Key: DROOLS-1373
> URL: https://issues.jboss.org/browse/DROOLS-1373
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: drools-1373.PNG
>
>
> I have attached a reproducer named NotRemovingRules.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 2 rules and removes 2 rules and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the last .dmp file created names ckpoint3.drl you will see that rules named like
> org.drools.compiler.integraionTests.Rule_120#0DefaultConsequenceInvoker are still present. However, if you examine the console or System.out you will notice the code is executing that is removing the rules from the KieModule/KieContainer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1373) Rules are not removed from the KieModule/KieContainer
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-1373:
-------------------------------------
Summary: Rules are not removed from the KieModule/KieContainer
Key: DROOLS-1373
URL: https://issues.jboss.org/browse/DROOLS-1373
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Bill Tuminaro
Assignee: Mario Fusco
I have attached a reproducer named NotRemovingRules.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 2 rules and removes 2 rules and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
If you examine the last .dmp file created names ckpoint3.drl you will see that rules named like
org.drools.compiler.integraionTests.Rule_120#0DefaultConsequenceInvoker are still present. However, if you examine the console or System.out you will notice the code is executing that is removing the rules from the KieModule/KieContainer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1372) Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1372?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1372:
----------------------------------
Description:
I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
If you examine the .dmp files name updrule#_3.dmp (i.e. updrule1_3.dmp , updrule3_3.dmp ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
was:
I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
If you examine the .dmp files name updrule#_3.drl (i.e. updrule1_3.drl , updrule3_3.drl ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
Steps to Reproduce: Run the attached reproducer and examine the updrule#_3.dmp (i.e. updrule1_3.dmp , updrule3_3.dmp ) files that are created. Notice the number org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker classloaders is increasing. (was: Run the attached reproducer and examine the updrule#_3.drl (i.e. updrule1_3.drl , updrule3_3.drl ) files that are created. Notice the number org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker classloaders is increasing.)
> Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1372
> URL: https://issues.jboss.org/browse/DROOLS-1372
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: UpdateToVersionCreatingNewClassloaders.java, drools-1372_one.PNG, drools-1372_two.PNG
>
>
> I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the .dmp files name updrule#_3.dmp (i.e. updrule1_3.dmp , updrule3_3.dmp ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months