[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool
by Bela Ban (JIRA)
Bela Ban created JGRP-2100:
------------------------------
Summary: Timer: don't submit non-blocking tasks to the thread pool
Key: JGRP-2100
URL: https://issues.jboss.org/browse/JGRP-2100
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool.
If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool.
Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2099) TP: one single thread pool
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2099:
---------------------------
Description:
Currently, TP has 4 thread pools:
* OOB
* Regular
* Internal
* Timer (used by TimeScheduler3)
The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
The new common pool would have the following characteristics:
* Default rejection policy of "abort" (so we can handle pool exhaustion)
* No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
* Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
* Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions
was:
Currently, TP has 4 thread pools:
* OOB
* Regular
* Internal
* Timer (used by TimeScheduler3)
The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
The new common pool would have the following characteristics:
* Default rejection policy of "abort" (so we can handle pool exhaustion)
* No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
* An additional parameter {{important}} for the {{execute()}} and {{scheduleXXX()}} methods. If set, a new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
* Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions
> TP: one single thread pool
> --------------------------
>
> Key: JGRP-2099
> URL: https://issues.jboss.org/browse/JGRP-2099
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
>
> Currently, TP has 4 thread pools:
> * OOB
> * Regular
> * Internal
> * Timer (used by TimeScheduler3)
> The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
> This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
> The new common pool would have the following characteristics:
> * Default rejection policy of "abort" (so we can handle pool exhaustion)
> * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
> * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
> * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-1765:
--------------------------------------
Labels: (was: deployment)
> unclear NullPointerException if the deployment-scanner element is removed from the configuration
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1765
> URL: https://issues.jboss.org/browse/WFCORE-1765
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Wolf-Dieter Fink
> Assignee: ehsavoie Hugonnet
>
> If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint.
> Config:
> {xml}
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <!-- deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/ -->
> </subsystem>
> {xml}
> Log message:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-1765:
--------------------------------------
Component/s: Domain Management
(was: Deployment Scanner)
> unclear NullPointerException if the deployment-scanner element is removed from the configuration
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1765
> URL: https://issues.jboss.org/browse/WFCORE-1765
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Wolf-Dieter Fink
> Assignee: ehsavoie Hugonnet
> Labels: deployment
>
> If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint.
> Config:
> {xml}
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <!-- deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/ -->
> </subsystem>
> {xml}
> Log message:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1765:
------------------------------------------
[~ehugonnet] If this isn't the scanner logic itself but is a kernel issue please change the component to Domain Management. Please also reassign the downstream JBEAP to yourself and fix the component.
> unclear NullPointerException if the deployment-scanner element is removed from the configuration
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1765
> URL: https://issues.jboss.org/browse/WFCORE-1765
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 2.0.10.Final
> Reporter: Wolf-Dieter Fink
> Assignee: ehsavoie Hugonnet
> Labels: deployment
>
> If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint.
> Config:
> {xml}
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <!-- deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/ -->
> </subsystem>
> {xml}
> Log message:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1768:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
> elytron module.xml, invalid package name in exclude
> ---------------------------------------------------
>
> Key: WFCORE-1768
> URL: https://issues.jboss.org/browse/WFCORE-1768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha8
>
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-6127.
------------------------------
WildFly 10.1.0.Final contains the fix for the reported issue. The discussion about extended persistence context belongs in a separate jira (or could be discussed on [wildfly-dev(a)lists.jboss.org]).
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6127:
-------------------------------
Affects Version/s: 10.0.0.Final
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2099) TP: one single thread pool
by Bela Ban (JIRA)
Bela Ban created JGRP-2099:
------------------------------
Summary: TP: one single thread pool
Key: JGRP-2099
URL: https://issues.jboss.org/browse/JGRP-2099
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Currently, TP has 4 thread pools:
* OOB
* Regular
* Internal
* Timer (used by TimeScheduler3)
The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks.
This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result.
The new common pool would have the following characteristics:
* Default rejection policy of "abort" (so we can handle pool exhaustion)
* No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed
* An additional parameter {{important}} for the {{execute()}} and {{scheduleXXX()}} methods. If set, a new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks
* Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6127:
------------------------------------
Please create a new [WFLY jira|https://issues.jboss.org/browse/WFLY] to discuss the proposed (extension) patch [https://github.com/argustelecom/wildfly/tree/WFLY-6127]. I have questions to ask about the change and whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. Please include the above two comments as well.
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months