[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3039:
------------------------------------------
I think the problem probably relates to the fact that OperationContext.deregisterCapabilityRequirement does not expose an 'attributeName' param so when the undefine-attribute removes the requirement it can get messed up. See CapabilityRegistry.removeRequirement. However, before anything can even be done with that, RequirementRegistration.registrationPoints is a Map<PathAddress, RegistrationPoint> so if 2 attributes for the same resource register, there will only be one entry in the map.
> Capability requirement can be lost if two attributes on same resource reference the same capability
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3039
> URL: https://issues.jboss.org/browse/WFCORE-3039
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Radovan Netuka
>
> With the following three commands the server becomes unable to boot due to a missing dependency: -
> {noformat}
> /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
> /subsystem=elytron:undefine-attribute(name=final-providers)
> /subsystem=elytron/aggregate-providers=combined-providers:remove
> {noformat}
> If however I execute :reload after the first two commands, the final command will fail correctly.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities:
> capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'",
> "rolled-back" => true
> }
> {noformat}
> I am only listing the 'Domain Management' component as I believe the security example is just the reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3039:
------------------------------------------
The code at your [1] is calling an API that per the issue that added it -- WFCORE-3683 -- is meant to "Allow a resource to declares capability requirements without binding it to an attribute." So I think null is the appropriate param.
The javadoc for IMRR.getRequirements() could/should be better.
> Capability requirement can be lost if two attributes on same resource reference the same capability
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3039
> URL: https://issues.jboss.org/browse/WFCORE-3039
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Radovan Netuka
>
> With the following three commands the server becomes unable to boot due to a missing dependency: -
> {noformat}
> /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
> /subsystem=elytron:undefine-attribute(name=final-providers)
> /subsystem=elytron/aggregate-providers=combined-providers:remove
> {noformat}
> If however I execute :reload after the first two commands, the final command will fail correctly.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities:
> capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'",
> "rolled-back" => true
> }
> {noformat}
> I am only listing the 'Domain Management' component as I believe the security example is just the reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2654) [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2654?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-2654:
----------------------------------------
I'll try easier with steps first, if required I can try a video.
1. the user click on "add new row"
2. the system add the new row above/below as expected
3. the textfield editor for the context entry text is automatically selected, in focus, and ready to edit the name
Currently the default is "My Name", hence means as soon as the new row is added, the user by typing on the keyboard can change the name
> [DMN Designer] Automatically show (Name) edit control when adding new ContextEntries
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-2654
> URL: https://issues.jboss.org/browse/DROOLS-2654
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> When a new {{ContextEntry}} is added the User must double click on the {{Name}} cell to change the default value.
> [~tari_manga] suggested it would be good if the {{Name}} editor was automatically shown and focused when the User creates a new {{ContextEntry}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-28:
------------------------------------
[~mnovak] What was the outcome of the re-run with traces?
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFWIP-18) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-18?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor reassigned WFWIP-18:
----------------------------------
Assignee: Francesco Nigro (was: Jeff Mesnil)
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFWIP-18
> URL: https://issues.jboss.org/browse/WFWIP-18
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFWIP-16) [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFWIP-16?page=com.atlassian.jira.plugin.s... ]
Martyn Taylor commented on WFWIP-16:
------------------------------------
Compiling against RHEL6 should be done as part of the productisation process.
> [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64
> -----------------------------------------------------------------
>
> Key: WFWIP-16
> URL: https://issues.jboss.org/browse/WFWIP-16
> Project: WildFly WIP
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> LibAIO does not get loaded on RHEL 6 x86_64:
> {code}
> [hudson@rhel6-large-2723 bin]$ sh standalone.sh -c standalone-full-ha.xml -Djboss.socket.binding.port-offset=1000
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /tmp/jboss-eap
> JAVA: java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> ...
> 10:14:31,918 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0075: AIO wasn't located on this platform, it will fall back to using pure Java NIO. Your platform is Linux, install LibAIO to enable the AIO journal and achieve optimal performance.
> 10:14:32,017 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/jboss-eap/standalone/data/activemq/journal,bindingsDirectory=/tmp/jboss-eap/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/jboss-eap/standalone/data/activemq/largemessages,pagingDirectory=/tmp/jboss-eap/standalone/data/activemq/paging)
> 10:14:32,110 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221013: Using NIO Journal
> ...
> {code}
> libAIO in artemis journal module from WF branch. Not from Artemis 2.5.0.Final tag.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months