[JBoss JIRA] (WFCORE-832) Access control exceptions missing for non-existent resources
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin... ]
Heiko Braun commented on WFCORE-832:
------------------------------------
+1
I agree with Brian. It needs to be predictable. Other then that it looks good to me.
> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
> Key: WFCORE-832
> URL: https://issues.jboss.org/browse/WFCORE-832
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Harald Pehl
> Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block:
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "replace-deployment" => {"execute" => false},
> "stop-servers" => {"execute" => false},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => false},
> "resume-servers" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => false},
> "reload-servers" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => false},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true}
> }
> },
> "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => true},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => true},
> "map-put" => {"execute" => true},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "resume-servers" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => true},
> "reload-servers" => {"execute" => true},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => true},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => true},
> "read-children-resources" => {"execute" => true}
> },
> "address" => [("server-group" => "main-server-group")]
> }}
> }
> }
> }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("server-group" => "*"),
> ("deployment" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {},
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "enabled" => {
> "read" => true,
> "write" => false
> },
> "name" => {
> "read" => true,
> "write" => false
> },
> "runtime-name" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "remove" => {"execute" => false},
> "deploy" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "redeploy" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true},
> "undeploy" => {"execute" => false}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
> Some notes on the domain:
> - Built from WildFly 10 master
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5477) Failback fails with ActiveMQIllegalStateException during synchronization with live server
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5477?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-5477:
---------------------------------
Description:
Sometimes happens that synchronization between live and backup fails during failback with exception ActiveMQIllegalStateException. It causes that live does not activate and backup stops so none of the servers is active to serve clients.
Test scenario:
1. Start 2 EAP 7.0.0.DR11 servers with Artemis configured in dedicated topology with replicated journal
-- 1st EAP server has Artemis configured as live, 2nd EAP server has Artemis configured as backup
-- queues InQueue and OutQueue are deployed
2. Send 2000 messages to InQueue to 1st server (live)
3. Start 3rd EAP 7.0.0.DR11 server with MDB consuming from remote InQueue and sending to remote OutQueue in XA transaction
-- resource adapter is configured for failover
4. Kill live server when MDB is processing messages
5. Wait for backup to activate and failover to happen
6. Start live server again and wait for failback
In step 6. sometimes happens that synchronization between live and backup fails during failback with exception:
{code}
10:05:13,493 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: ActiveMQIllegalStateException[errorType=I
LLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live]
at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:232) [artemis-server-1.1.0.jar:1.1.0]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
{code}
and live server never activates. Also backup server stops with:
{code}
10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0 [706b0cb8-6b69-11e5-904d-fd646d33ece8] stopped
10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221039: Restarting as Replicating backup server after live restart
{code}
so live/backup pair is dead and server with MDB looses connection.
Attaching logs from servers and configurations.
was:
Sometimes happens that synchronization between live and backup fails during failback with exception ActiveMQIllegalStateException. It causes that live does not activate and backup stops so none of the servers is active to serve clients.
Test scenario:
1. Start 2 EAP 7.0.0.DR11 servers with Artemis configured in dedicated topology with replicated journal
- 1st EAP server has Artemis configured as live, 2nd EAP server has Artemis configured as backup
- queues InQueue and OutQueue are deployed
2. Send 2000 messages to InQueue to 1st server (live)
3. Start 3rd EAP 7.0.0.DR11 server with MDB consuming from remote InQueue and sending to remote OutQueue in XA transaction
- resource adapter is configured for failover
4. Kill live server when MDB is processing messages
5. Wait for backup to activate and failover to happen
6. Start live server again and wait for failback
In step 6. sometimes happens that synchronization between live and backup fails during failback with exception:
{code}
10:05:13,493 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: ActiveMQIllegalStateException[errorType=I
LLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live]
at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:232) [artemis-server-1.1.0.jar:1.1.0]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
{code}
and live server never activates. Also backup server stops with:
{code}
10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0 [706b0cb8-6b69-11e5-904d-fd646d33ece8] stopped
10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221039: Restarting as Replicating backup server after live restart
{code}
so live/backup pair is dead and server with MDB looses connection.
Attaching logs from servers and configurations.
> Failback fails with ActiveMQIllegalStateException during synchronization with live server
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5477
> URL: https://issues.jboss.org/browse/WFLY-5477
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: backup-logs.zip, live-logs.zip, mdb-server-logs.zip, standalone-full-ha-backup.xml, standalone-full-ha-live.xml, standalone-full-ha-mdb.xml
>
>
> Sometimes happens that synchronization between live and backup fails during failback with exception ActiveMQIllegalStateException. It causes that live does not activate and backup stops so none of the servers is active to serve clients.
> Test scenario:
> 1. Start 2 EAP 7.0.0.DR11 servers with Artemis configured in dedicated topology with replicated journal
> -- 1st EAP server has Artemis configured as live, 2nd EAP server has Artemis configured as backup
> -- queues InQueue and OutQueue are deployed
> 2. Send 2000 messages to InQueue to 1st server (live)
> 3. Start 3rd EAP 7.0.0.DR11 server with MDB consuming from remote InQueue and sending to remote OutQueue in XA transaction
> -- resource adapter is configured for failover
> 4. Kill live server when MDB is processing messages
> 5. Wait for backup to activate and failover to happen
> 6. Start live server again and wait for failback
> In step 6. sometimes happens that synchronization between live and backup fails during failback with exception:
> {code}
> 10:05:13,493 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: ActiveMQIllegalStateException[errorType=I
> LLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:232) [artemis-server-1.1.0.jar:1.1.0]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {code}
> and live server never activates. Also backup server stops with:
> {code}
> 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0 [706b0cb8-6b69-11e5-904d-fd646d33ece8] stopped
> 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221039: Restarting as Replicating backup server after live restart
> {code}
> so live/backup pair is dead and server with MDB looses connection.
> Attaching logs from servers and configurations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5477) Failback fails with ActiveMQIllegalStateException during synchronization with live server
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5477?page=com.atlassian.jira.plugin.... ]
Miroslav Novak moved JBEAP-1240 to WFLY-5477:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5477 (was: JBEAP-1240)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: JMS
(was: JMS)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR2
(was: 7.0.0.DR11 (Alpha))
> Failback fails with ActiveMQIllegalStateException during synchronization with live server
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5477
> URL: https://issues.jboss.org/browse/WFLY-5477
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: backup-logs.zip, live-logs.zip, mdb-server-logs.zip, standalone-full-ha-backup.xml, standalone-full-ha-live.xml, standalone-full-ha-mdb.xml
>
>
> Sometimes happens that synchronization between live and backup fails during failback with exception ActiveMQIllegalStateException. It causes that live does not activate and backup stops so none of the servers is active to serve clients.
> Test scenario:
> 1. Start 2 EAP 7.0.0.DR11 servers with Artemis configured in dedicated topology with replicated journal
> - 1st EAP server has Artemis configured as live, 2nd EAP server has Artemis configured as backup
> - queues InQueue and OutQueue are deployed
> 2. Send 2000 messages to InQueue to 1st server (live)
> 3. Start 3rd EAP 7.0.0.DR11 server with MDB consuming from remote InQueue and sending to remote OutQueue in XA transaction
> - resource adapter is configured for failover
> 4. Kill live server when MDB is processing messages
> 5. Wait for backup to activate and failover to happen
> 6. Start live server again and wait for failback
> In step 6. sometimes happens that synchronization between live and backup fails during failback with exception:
> {code}
> 10:05:13,493 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: ActiveMQIllegalStateException[errorType=I
> LLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:232) [artemis-server-1.1.0.jar:1.1.0]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {code}
> and live server never activates. Also backup server stops with:
> {code}
> 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0 [706b0cb8-6b69-11e5-904d-fd646d33ece8] stopped
> 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221039: Restarting as Replicating backup server after live restart
> {code}
> so live/backup pair is dead and server with MDB looses connection.
> Attaching logs from servers and configurations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-1034) 2 step domain operations do not resolve aliases properly
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-1034:
----------------------------------
Summary: 2 step domain operations do not resolve aliases properly
Key: WFCORE-1034
URL: https://issues.jboss.org/browse/WFCORE-1034
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR6
Reporter: Kabir Khan
Assignee: Kabir Khan
Priority: Critical
Fix For: 2.0.0.CR7
For WFLY-5290, WFCORE-1022 was done to provide more context, however we still have some problems when doing:
{code}
/profile=full-ha/subsystem=jgroups/stack=tcp/transport=TRANSPORT/thread-pool=default:write-attribute(name=keepalive-time,value=100)
{code}
This is an alias which should resolve to
{code}
/profile=full-ha/subsystem=jgroups/stack=tcp/transport=TCP/thread-pool=default:write-attribute(name=keepalive-time,value=100)
{code}
The equivalent works fine in a standalone. Debugging using CLI commands, the initial read-operation-description ends up in PrepareStepHandler.executeDirectOperation()
which does the right thing.
However the write-attribute call ends up in
{code}
OperationCoordinatorStepHandler.execute() ->
OperationSlaveStepHandler.addSteps() ->
HostControllerExecutionSupport returns a domainOp ->
OperationSlaveStepHandler.addBasicStep()
{code}
and OperationSlaveStepHandler.addBasicStep() resolves the OperationEntry differently from the standard/standalone prepare step handler, and from how PrepareStepHandler.executeDirectOperation() resolves it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5453) NPE during backup activation in collocated HA topology
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5453?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5453:
------------------------------
Workaround Description:
add an explicit slave configuration
{noformat}
<replication-colocated backup-port-offset="50" request-backup="true">
<slave/>
</replication-colocated>
{noformat}
Workaround: Workaround Exists
> NPE during backup activation in collocated HA topology
> ------------------------------------------------------
>
> Key: WFLY-5453
> URL: https://issues.jboss.org/browse/WFLY-5453
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> If there are 2 EAP 7.0.0.DR11(Artemis 1.1.0) in collocated HA topology with replicated journal then backup does not activate after one server is killed. There is NPE in log of 2nd EAP server:
> {code}
> 10:13:12,231 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> at java.lang.Thread.run(Thread.java:745)
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> 10:13:12,236 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)
> {code}
> Attaching configuration of both of the servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5453) NPE during backup activation in collocated HA topology
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5453?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5453:
-----------------------------------
The NPE is on the replicaPolicy's replicatedPolicy.
The issue looks to be on the creation of the replicaPolicy that is using the no-op ctor in org.apache.activemq.artemis.core.config.ConfigurationUtils#getHAPolicy when creating a COLOCATED policy with backup.
If we explicitly create a backup configuration, the NPE no longer occurs:
{noformat}
<replication-colocated backup-port-offset="50" request-backup="true">
<slave/>
</replication-colocated>
{noformat}
Note that in this case, the backup configuration is made only of default values.
> NPE during backup activation in collocated HA topology
> ------------------------------------------------------
>
> Key: WFLY-5453
> URL: https://issues.jboss.org/browse/WFLY-5453
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> If there are 2 EAP 7.0.0.DR11(Artemis 1.1.0) in collocated HA topology with replicated journal then backup does not activate after one server is killed. There is NPE in log of 2nd EAP server:
> {code}
> 10:13:12,231 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> at java.lang.Thread.run(Thread.java:745)
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> 10:13:12,236 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)
> {code}
> Attaching configuration of both of the servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-1882) JCA should be able to access the CDI-enabled ValidatorFactory
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1882?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-1882:
-------------------------------------
Hi [~fjuma] I noticed this has the 10.0.0.Final fixVersion on it - is it definitely intended for that release or would 11+ be OK also?
> JCA should be able to access the CDI-enabled ValidatorFactory
> -------------------------------------------------------------
>
> Key: WFLY-1882
> URL: https://issues.jboss.org/browse/WFLY-1882
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Farah Juma
> Assignee: Stefano Maestri
> Fix For: 10.0.0.Final
>
>
> The JCAValidatorFactory is currently a copy of an older version of the EE LazyValidatorFactory. The delegate of the EE LazyValidatorFactory was recently replaced with a CDI-enabled ValidatorFactory (see WFLY-529). JCA needs to be able to access the CDI-enabled ValidatorFactory as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5453) NPE during backup activation in collocated HA topology
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5453?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-5453:
---------------------------------
Priority: Blocker (was: Critical)
> NPE during backup activation in collocated HA topology
> ------------------------------------------------------
>
> Key: WFLY-5453
> URL: https://issues.jboss.org/browse/WFLY-5453
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> If there are 2 EAP 7.0.0.DR11(Artemis 1.1.0) in collocated HA topology with replicated journal then backup does not activate after one server is killed. There is NPE in log of 2nd EAP server:
> {code}
> 10:13:12,231 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> at java.lang.Thread.run(Thread.java:745)
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
> 10:13:12,235 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> 10:13:12,236 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)
> {code}
> Attaching configuration of both of the servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5462) IllegalStateException: UT010055: Listener is not started during application undeployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5462?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5462.
----------------------------------
Resolution: Rejected
When an app is shutting down while still under load anything can happen, as active requests are relying on services that are going away. Suspend/resume (graceful shutdown) is our solution to this.
> IllegalStateException: UT010055: Listener is not started during application undeployment
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-5462
> URL: https://issues.jboss.org/browse/WFLY-5462
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Stuart Douglas
> Priority: Minor
>
> Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenario:
> http-session-undeploy-dist-async
> http-session-undeploy-dist-sync
> During application undeployment, this error message was logged approx. 15 times - stacktrace:
> {code}
> 2015/09/30 04:32:17:342 EDT [DEBUG][RMI TCP Connection(12)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Requesting: {
> "operation" : "undeploy",
> "address" : [{
> "deployment" : "clusterbench-ee7.ear"
> }]
> }
> :
> [JBossINF] [0m[0m04:32:18,797 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 85) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m04:32:18,799 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 85) ISPN000030: Passivated 1 entries in 1 milliseconds
> [JBossINF] [0m[0m04:32:18,806 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 85) ISPN000310: Starting cluster-wide rebalance for cache dist, topology CacheTopology{id=13, rebalanceId=6, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf21: 31+9, perf20: 25+15, perf18: 24+16]}, pendingCH=DefaultConsistentHash{ns=80, owners = (3)[perf21: 27+26, perf20: 26+28, perf18: 27+26]}, unionCH=null, actualMembers=[perf21, perf20, perf18]}
> [JBossINF] [0m[0m04:32:18,806 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0003: Stopped dist cache from ejb container
> [JBossINF] [0m[0m04:32:18,832 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[0m04:32:18,833 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel ejb
> [JBossINF] [0m[0m04:32:18,958 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 84) ISPN000030: Passivated 3027 entries in 324 milliseconds
> [JBossINF] [0m[31m04:32:18,968 ERROR [io.undertow.request] (default task-30) UT005023: Exception handling request to /clusterbench/session: java.lang.IllegalStateException: UT010055: Listener is not started
> [JBossINF] at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:74)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:356)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months