[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)
9 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)
9 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)
9 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)
9 years, 11 months
[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE
by Jiri Locker (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ]
Jiri Locker reopened DROOLS-1186:
---------------------------------
Hi, I hit the NPE again while working on DROOLS-1187. I've isolated as much as possible. There is only a single rule in score DRL and 13 facts inserted into WM. The exception occurs in move 29 and depends on move 28, the previous 28 moves are skipped (not evaluated).
Please take a look at https://github.com/yurloc/optaplanner/tree/drools-1187-NPE. The README contains steps to reproduce and also the test output.
> Setting the planning variable nullable in nurserostering examples causes Drools NPE
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1186
> URL: https://issues.jboss.org/browse/DROOLS-1186
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1.
> Reporter: Julio Bellon Aguilera
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
> Attachments: PLANNER_488.patch
>
>
> If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException.
> fixed that, causes the first NPE, and fixed that, causes other NPE unfixed:
> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException:
> Caused by: java.lang.NullPointerException
> at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-548) Adjust the HTTP Authenticator so the first non OK status code wins.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-548:
------------------------------------
Summary: Adjust the HTTP Authenticator so the first non OK status code wins.
Key: ELY-548
URL: https://issues.jboss.org/browse/ELY-548
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
Later mechanisms may perform an action that prevents the status code from being subsequently set so the first mechanism to select a status code that is not 200 should 'win'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1192) DialectUtil.normalizeRuleName() doesn't normalize multibyte rule names
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1192?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1192.
-------------------------------
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/1f85d0324
> DialectUtil.normalizeRuleName() doesn't normalize multibyte rule names
> ----------------------------------------------------------------------
>
> Key: DROOLS-1192
> URL: https://issues.jboss.org/browse/DROOLS-1192
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> Assuming you have a rule name "rule（hello）",
> {noformat}
> package com.sample
> rule "rule（hello）"
> when
> then
> end
> {noformat}
> Here, ' （' and '）' ... U+FF08 (FULLWIDTH LEFT PARENTHESIS) and U+FF09 (FULLWIDTH RIGHT PARENTHESIS) are not a Java identifier part. The rule fails to compile.
> {noformat}
> Rule Compilation error : [Rule name='rule（hello）']
> com/sample/Rule_rule（hello）0.java (3:84) : Syntax error on tokens, delete these tokens
> com/sample/Rule_rule（hello）0.java (3:97) : The public type Rule_rule must be defined in its own file
> com/sample/Rule_rule（hello）0.java (3:115) : Syntax error, insert "}" to complete Block
> com/sample/Rule_rule（hello）0.java (4:121) : Syntax error on tokens, delete these tokens
> com/sample/Rule_rule（hello）0.java (6:187) : Syntax error on token "void", @ expected
> com/sample/Rule_rule（hello）0.java (6:211) : Syntax error on token(s), misplaced construct(s)
> com/sample/Rule_rule（hello）0.java (6:238) : Syntax error on token "throws", @ expected
> com/sample/Rule_rule（hello）0.java (6:255) : Syntax error, insert "enum Identifier" to complete EnumHeader
> com/sample/Rule_rule（hello）0.java (11:332) : Syntax error on token "}", delete this token
> {noformat}
> But such a non-java identifier part should be normalized by org.drools.compiler.rule.builder.dialect.DialectUtil.normalizeRuleName() during the build. The problem is that DialectUtil.normalizeRuleName() misses to process the name because of NON_ALPHA_REGEX check. NON_ALPHA_REGEX doesn't take account into Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6652) Warning when stopping a server with a deployed MDB listening to a topic
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6652?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6652:
------------------------------
Description:
How to reproduce:
* start WildFly *with ActiveMQ security for in-vm (override-in-vm-security=false)* and a pooled-connection-factory with user credentials (see attached configuration)
* deploy the regular helloworld-mdb quickstart
* stop WildFly (with Ctl+C)
The server logs a warning:
{noformat}
17:48:54,217 WARN [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=1c98f514-2290-11e6-a581-c1ccabba71e3-1850673655-879332228)) Sending unexpected exception to the client: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.security.auth.Subject.container
at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:96)
at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:90)
at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.security.plugins.SubjectActions.getActiveSubject(SubjectActions.java:316)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:331)
at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:148)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:105)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:78)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager.validateUserAndRole(WildFlySecurityManager.java:78)
at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:162)
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1272)
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1243)
at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.deleteQueue(ServerSessionImpl.java:598)
at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:244)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:626)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:349)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:331)
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:616)
at org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:171)
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
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)
{noformat}
When the server is stopped, ActiveMQ RA will attempt to destroy the core queue corresponding to the MDB listening on the JMS topic.
On the broker side, the exception occurs because there is no dependency between the pooled-connection-factory's service and the boostrap security service that handles the javax.security.auth.Subject.container context.
was:
How to reproduce:
* start WildFly *with ActiveMQ security for in-vm(override-in-vm-security=false)* and a pooled-connection-factory with user credentials (see attached configuration)
* deploy the regular helloworld-mdb quickstart
* stop WildFly (with Ctl+C)
The server logs a warning:
{noformat}
17:48:54,217 WARN [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=1c98f514-2290-11e6-a581-c1ccabba71e3-1850673655-879332228)) Sending unexpected exception to the client: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.security.auth.Subject.container
at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:96)
at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:90)
at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:82)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.security.plugins.SubjectActions.getActiveSubject(SubjectActions.java:316)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:331)
at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:148)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:105)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:78)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.extension.messaging.activemq.WildFlySecurityManager.validateUserAndRole(WildFlySecurityManager.java:78)
at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:162)
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1272)
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1243)
at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.deleteQueue(ServerSessionImpl.java:598)
at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:244)
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:626)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:349)
at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:331)
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:616)
at org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:171)
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
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)
{noformat}
When the server is stopped, ActiveMQ RA will attempt to destroy the core queue corresponding to the MDB listening on the JMS topic.
On the broker side, the exception occurs because there is no dependency between the pooled-connection-factory's service and the boostrap security service that handles the javax.security.auth.Subject.container context.
> Warning when stopping a server with a deployed MDB listening to a topic
> -----------------------------------------------------------------------
>
> Key: WFLY-6652
> URL: https://issues.jboss.org/browse/WFLY-6652
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: standalone-full.xml
>
>
> How to reproduce:
> * start WildFly *with ActiveMQ security for in-vm (override-in-vm-security=false)* and a pooled-connection-factory with user credentials (see attached configuration)
> * deploy the regular helloworld-mdb quickstart
> * stop WildFly (with Ctl+C)
> The server logs a warning:
> {noformat}
> 17:48:54,217 WARN [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=1c98f514-2290-11e6-a581-c1ccabba71e3-1850673655-879332228)) Sending unexpected exception to the client: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.security.auth.Subject.container
> at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:96)
> at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:90)
> at org.jboss.security.plugins.SubjectActions$GetSubjectAction.run(SubjectActions.java:82)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.security.plugins.SubjectActions.getActiveSubject(SubjectActions.java:316)
> at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:331)
> at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:148)
> at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:105)
> at org.wildfly.extension.messaging.activemq.WildFlySecurityManager$1.run(WildFlySecurityManager.java:78)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.extension.messaging.activemq.WildFlySecurityManager.validateUserAndRole(WildFlySecurityManager.java:78)
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:162)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1272)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:1243)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.deleteQueue(ServerSessionImpl.java:598)
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:244)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:626)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:349)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:331)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:616)
> at org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:171)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
> 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)
> {noformat}
> When the server is stopped, ActiveMQ RA will attempt to destroy the core queue corresponding to the MDB listening on the JMS topic.
> On the broker side, the exception occurs because there is no dependency between the pooled-connection-factory's service and the boostrap security service that handles the javax.security.auth.Subject.container context.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months