[JBoss JIRA] (WFLY-6152) EJB timer scheduler log an Exception for an already canceled timer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6152?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6152:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1305960|https://bugzilla.redhat.com/show_bug.cgi?id=1305960] from ON_QA to VERIFIED
> EJB timer scheduler log an Exception for an already canceled timer
> ------------------------------------------------------------------
>
> Key: WFLY-6152
> URL: https://issues.jboss.org/browse/WFLY-6152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Minor
> Labels: timer, timers, timerservice
> Fix For: 10.1.0.Final
>
>
> If a timer is canceled inside of the @timeout method the scheduler will log an ERROR if the timer duration is longer than the intervall and an overlapping execution should be fired.
> This is due to internal validatons.
> This will not happen if the timer is canceled by an external process, here the scheduler is removed.
> The log message is like this:
> ERROR [org.jboss.as.ejb3] (EJB default - 3) WFLYEJB0164: Exception running timer task for timer [id=0bd9870b-568b-42f5-9bda-e1525c3500aa timedObjectId=ejb30-timer.ejb30-timer.SimpleTimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@53ba1a7f initialExpiration=Tue Feb 09 17:19:32 CET 2016 intervalDuration(in milli sec)=5000 nextExpiration=Tue Feb 09 17:19:37 CET 2016 timerState=CANCELED info=SimpleTimerInfo description=A timer started every 5 seconds] on EJB ejb30-timer.ejb30-timer.SimpleTimerBean: javax.ejb.NoSuchObjectLocalException: WFLYEJB0331: Timer was canceled
> at org.jboss.as.ejb3.timerservice.TimerImpl.assertTimerState(TimerImpl.java:459)
> at org.jboss.as.ejb3.timerservice.TimerImpl.isPersistent(TimerImpl.java:215)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Hi Miroslav,
Sorry I think both of us added the comment at the same time. I will setup the cluster on my local environment and then send you the logs and other details.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla commented on WFLY-6781:
----------------------------------------
Thanks Paul.
Below is the messaging subsystem declared in the domain.xml.
{color:#205081}<profile name="ha">
<subsystem xmlns="urn:jboss:domain:messaging:2.0">
<hornetq-server>
<security-enabled>false</security-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector" socket-binding="remote-http">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput" socket-binding="http">
<param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default" name="http-acceptor"/>
<http-acceptor http-listener="default" name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>
<security-settings>
<security-setting match="#">
<permission type="send" roles="jmsrole guest"/>
<permission type="consume" roles="jmsrole guest"/>
<permission type="createDurableQueue" roles="jmsrole"/>
<permission type="deleteDurableQueue" roles="jmsrole"/>
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
</security-setting>
</security-settings>
<address-settings>
<address-setting match="#">
<dead-letter-address>jms.queue.DLQ</dead-letter-address>
<expiry-address>jms.queue.ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<max-size-bytes>10485760</max-size-bytes>
<address-full-policy>BLOCK</address-full-policy>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
</address-setting>
</address-settings>
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="/ConnectionFactory"/>
</entries>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="http-connector"/>
</connectors>
<entries>
<entry name="jms/RemoteConnectionFactory"/>
<entry name="jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
<connection-ttl>-1</connection-ttl>
<reconnect-attempts>-1</reconnect-attempts>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="/JmsXA"/>
<entry name="jboss/DefaultJMSConnectionFactory"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
<jms-destinations>
<jms-queue name="testQueue">
<entry name="queue/test"/>
<entry name="jboss/exported/jms/queue/test"/>
</jms-queue>
<jms-queue name="ISEEOutboundQueue">
<entry name="jms/ISEEOutboundQueue"/>
<entry name="jboss/exported/jms/queue/ISEEOutboundQueue"/>
</jms-queue>
<jms-queue name="ISEEInboundQueue">
<entry name="jms/ISEEInboundQueue"/>
<entry name="jboss/exported/jms/queue/ISEEInboundQueue"/>
</jms-queue>
<jms-queue name="BEEEAuthorizationsQueue">
<entry name="jms/BEEEAuthorizationsQueue"/>
<entry name="jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
</jms-queue>
<jms-queue name="BEEERequisitionsQueue">
<entry name="jms/BEEERequisitionsQueue"/>
<entry name="jboss/exported/jms/queue/BEEERequisitionsQueue"/>
</jms-queue>
<jms-queue name="BEEEInboundQueue">
<entry name="jms/BEEEInboundQueue"/>
<entry name="jboss/exported/jms/queue/BEEEInboundQueue"/>
</jms-queue>
<jms-topic name="testTopic">
<entry name="topic/test"/>
<entry name="jboss/exported/jms/topic/test"/>
</jms-topic>
</jms-destinations>
</hornetq-server>
</subsystem>{color}
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
Do you think you could provide server logs from node1 and node2 when you power off the machine? Could you also attach domain.xml and provide some sources of your deployments? It would greatly speed up solving the issue. Any kind of test deployments where we could reproduce the issue, it would help a lot.
You mentioned that RC.war is in cluster. I believe you mean the infinispan cluster for web which is using Infinispan. There is also JMS cluster which is something completely different as HornetQ (JMS provider) is doing cluster on its own.
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Jorge Solorzano updated WFCORE-1615:
------------------------------------
Description:
To make both scripts more consistent in terms of functionality.
Changes include:
* Add LSB INIT INFO
* Validate user and permisions.
* Make output of status more standard.
* Improve output messages.
* Include WFCORE-1604
Tested enviroments:
* CentOS 6.8
* CentoOS 7.2
* Fedora 24 Server
The script should be functional on both pre-systemd and systemd without weird behaivior.
was:
To make both scripts more consistent in terms of functionality.
Changes include:
*
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Priority: Trivial
>
> To make both scripts more consistent in terms of functionality.
> Changes include:
> * Add LSB INIT INFO
> * Validate user and permisions.
> * Make output of status more standard.
> * Improve output messages.
> * Include WFCORE-1604
> Tested enviroments:
> * CentOS 6.8
> * CentoOS 7.2
> * Fedora 24 Server
> The script should be functional on both pre-systemd and systemd without weird behaivior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Jorge Solorzano updated WFCORE-1615:
------------------------------------
Description:
To make both scripts more consistent in terms of functionality.
Changes include:
* Add LSB INIT INFO
* Validate user and permisions.
* Make output of status more standard.
* Improve output messages.
* Include WFCORE-1604
Tested enviroments:
* CentOS 6.8
* CentOS 7.2
* Fedora 24 Server
The script should be functional on both pre-systemd and systemd without weird behaivior.
was:
To make both scripts more consistent in terms of functionality.
Changes include:
* Add LSB INIT INFO
* Validate user and permisions.
* Make output of status more standard.
* Improve output messages.
* Include WFCORE-1604
Tested enviroments:
* CentOS 6.8
* CentoOS 7.2
* Fedora 24 Server
The script should be functional on both pre-systemd and systemd without weird behaivior.
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Priority: Trivial
>
> To make both scripts more consistent in terms of functionality.
> Changes include:
> * Add LSB INIT INFO
> * Validate user and permisions.
> * Make output of status more standard.
> * Improve output messages.
> * Include WFCORE-1604
> Tested enviroments:
> * CentOS 6.8
> * CentOS 7.2
> * Fedora 24 Server
> The script should be functional on both pre-systemd and systemd without weird behaivior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Jorge Solorzano updated WFCORE-1615:
------------------------------------
Description:
To make both scripts more consistent in terms of functionality.
Changes include:
*
was:To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Priority: Trivial
>
> To make both scripts more consistent in terms of functionality.
> Changes include:
> *
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Jorge Solorzano updated WFCORE-1615:
------------------------------------
Summary: Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (was: Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh (WFCORE-1121))
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Priority: Trivial
>
> To make both scripts more consistent in terms of functionality, WFCORE-1121 apply changes to wildfly-init-redhat.sh scripts but not to wildfly-init-debian.sh. This jira is to mimic the change back to wildfly-init-debian.sh
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1630?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1630:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1644, https://github.com/wildfly/wildfly-core/pull/1608 (was: https://github.com/wildfly/wildfly-core/pull/1644)
> Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1630
> URL: https://issues.jboss.org/browse/WFCORE-1630
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.2.0.CR5, 3.0.0.Alpha3
>
>
> When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
> {noformat}
> [Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months
[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1630:
-----------------------------------
Summary: Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
Key: WFCORE-1630
URL: https://issues.jboss.org/browse/WFCORE-1630
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.10.Final
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
{noformat}
[Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 10 months