May 2016 - jboss-jira - Jboss List Archives

[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: ------------------------------ Attachment: standalone-full.xml > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-6434) System property 'org.jboss.as.security.jacc-module' not always used

by Winfried Wasser (JIRA)

[ https://issues.jboss.org/browse/WFLY-6434?page=com.atlassian.jira.plugin.... ] Winfried Wasser updated WFLY-6434: ---------------------------------- Fix Version/s: 10.1.0.Final > System property 'org.jboss.as.security.jacc-module' not always used > ------------------------------------------------------------------- > > Key: WFLY-6434 > URL: https://issues.jboss.org/browse/WFLY-6434 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Winfried Wasser > Assignee: Darran Lofthouse > Fix For: 10.1.0.Final > > Attachments: security.patch > > > JaccService of security subsystem does not use the system property 'org.jboss.as.security.jacc-module' for class loader. > Due to this "not using", the custom JACC module is not used. > This property was introduced by WFLY-5340 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6652) Warning when stopping a server with a deployed MDB listening to a topic

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-6652: --------------------------------- Summary: 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 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

1
0
0 / 0

[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6294: -------------------------------- Labels: downstream_dependency (was: ) > Session draining always takes maximum configured timeout > -------------------------------------------------------- > > Key: WFLY-6294 > URL: https://issues.jboss.org/browse/WFLY-6294 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Radoslav Husar > Priority: Blocker > Labels: downstream_dependency > > The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session: > {code} > while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) { > ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context); > listener.wait(noTimeout ? 0 : timeout); > current = System.currentTimeMillis(); > timeout = end - current; > remainingSessions = context.getActiveSessionCount(); > } > {code} > Can the listeners be invoked when the session is fully removed and no longer considered active? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6294: -------------------------------- Priority: Blocker (was: Minor) > Session draining always takes maximum configured timeout > -------------------------------------------------------- > > Key: WFLY-6294 > URL: https://issues.jboss.org/browse/WFLY-6294 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Radoslav Husar > Priority: Blocker > Labels: downstream_dependency > > The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session: > {code} > while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) { > ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context); > listener.wait(noTimeout ? 0 : timeout); > current = System.currentTimeMillis(); > timeout = end - current; > remainingSessions = context.getActiveSessionCount(); > } > {code} > Can the listeners be invoked when the session is fully removed and no longer considered active? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6360) Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6360?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6360: -------------------------------- Priority: Blocker (was: Major) > Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2 > ----------------------------------------- > > Key: WFLY-6360 > URL: https://issues.jboss.org/browse/WFLY-6360 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Bartosz Baranowski > Assignee: Darran Lofthouse > Priority: Blocker > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6402: -------------------------------- Labels: downstream_dependency (was: ) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6650) Cannot enable infinispan batching

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6650?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-6650. ------------------------------ Resolution: Won't Fix We don't support Infinispan's invocation-batching as it lacks support for suspend/resume. <transaction mode="BATCH"/> will use a custom implementation of startBatch()/endBatch(). You work around this (for use by TreeCache) by creating a programmatic configuration with invocation batching enabled. > Cannot enable infinispan batching > --------------------------------- > > Key: WFLY-6650 > URL: https://issues.jboss.org/browse/WFLY-6650 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Julien Guillot > Assignee: Paul Ferraro > Priority: Minor > > Creating a TreeCache from a cache configured in standalone.xml fails with error:"invocationBatching is not enabled", whereas cache is configured with transaction mode BATCH. I'm not sure this configuration is right, [documentation|https://docs.jboss.org/author/display/WFLY10/Infinispan+Sub...] seems outdated. > Cache configuration is: > {noformat} > <cache-container name="testContainer" jndi-name="java:jboss/infinispan/container/testContainer"> > <local-cache name="testCache"> > <transaction mode="BATCH"/> > <eviction strategy="LRU" max-entries="43210"/> > </local-cache> > </cache-container> > {noformat} > Tree cache creation code: > {code:java} > @Resource(lookup = "java:jboss/infinispan/cache/testContainer/testCache") > private Cache<String, String> testBaseCache; > @PostConstruct > public void onStartup() { > debugInfo(); > new TreeCacheFactory().createTreeCache(this.testBaseCache); > } > {code} > Error: > {noformat} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC000001: Failed to start service jboss.deployment.subunit."test-wfy10-cache-tree.ear-0.0.0-SNAPSHOT.ear"."test-wfy10-cache-tree.jar.jar".component.TreeCacheBean.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."test-wfy10-cache-tree.ear-0.0.0-SNAPSHOT.ear"."test-wfy10-cache-tree.jar.jar".component.TreeCacheBean.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6360) Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6360?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6360: -------------------------------- Labels: downstream_dependency (was: ) > Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2 > ----------------------------------------- > > Key: WFLY-6360 > URL: https://issues.jboss.org/browse/WFLY-6360 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Bartosz Baranowski > Assignee: Darran Lofthouse > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6360) Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-6360?page=com.atlassian.jira.plugin.... ] Carlo de Wolf updated WFLY-6360: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8930 > Upgrade picketlink 2.5.5.SP1 to 2.5.5.SP2 > ----------------------------------------- > > Key: WFLY-6360 > URL: https://issues.jboss.org/browse/WFLY-6360 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Bartosz Baranowski > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016