[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2627:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1180556|https://bugzilla.redhat.com/show_bug.cgi?id=1180556] from NEW to ON_QA
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4326) Enable JPA meterics, all metrics zero
by Tim Mickelson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4326?page=com.atlassian.jira.plugin.... ]
Tim Mickelson commented on WFLY-4326:
-------------------------------------
Ok I did that, my question was on this discussion though, since the other discussion was about the transaction metrics, not the JPA metrics. Well anyway I added an image there.
> Enable JPA meterics, all metrics zero
> -------------------------------------
>
> Key: WFLY-4326
> URL: https://issues.jboss.org/browse/WFLY-4326
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 8.2.0.Final
> Environment: Windows 7, Ubuntu 14.04, CentOS, JDK1.7
> Reporter: Tim Mickelson
> Assignee: Scott Marlow
> Labels: jpa
>
> Enable JPA on any ear deployd on server and no metrics are presented. The datasource is JTA enabled and the same deployments (ears) deployd on JBoss 7.1.1 result in non zero metrics when JPA is enabled per ear on JBoss 7.1.1.
> Note: I have a very similar issue with the transaction metrics WFLY-4323
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4329) Can't update alias attribute of host element from jboss-cli
by Kohei Nozaki (JIRA)
[ https://issues.jboss.org/browse/WFLY-4329?page=com.atlassian.jira.plugin.... ]
Kohei Nozaki closed WFLY-4329.
------------------------------
Resolution: Rejected
Already fixed in snapshot
> Can't update alias attribute of host element from jboss-cli
> -----------------------------------------------------------
>
> Key: WFLY-4329
> URL: https://issues.jboss.org/browse/WFLY-4329
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK8u20
> Reporter: Kohei Nozaki
> Assignee: Stuart Douglas
>
> UPDATE: sorry, I pasted wrong one of error.
> I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
> jboss-cli gives following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=www.example.com)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> {code}
> Stacktraces in WildFly console:
> {code}
> 10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4329) Can't update alias attribute of host element from jboss-cli
by Kohei Nozaki (JIRA)
[ https://issues.jboss.org/browse/WFLY-4329?page=com.atlassian.jira.plugin.... ]
Kohei Nozaki commented on WFLY-4329:
------------------------------------
I'm sorry, please close this issue as rejected or something. just I found the problem is fixed in latest snapshot, and it gives descriptive error message already as follows.
{code}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=www.example.com)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0097: Wrong type for alias. Expected [LIST] but was STRING",
"rolled-back" => true
}
{code}
Also note that following command is works for both of 8.2.0.Final and latest snapshot.
{code}
/subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=["www.example.com"])
{code}
> Can't update alias attribute of host element from jboss-cli
> -----------------------------------------------------------
>
> Key: WFLY-4329
> URL: https://issues.jboss.org/browse/WFLY-4329
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK8u20
> Reporter: Kohei Nozaki
> Assignee: Stuart Douglas
>
> UPDATE: sorry, I pasted wrong one of error.
> I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
> jboss-cli gives following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=www.example.com)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> {code}
> Stacktraces in WildFly console:
> {code}
> 10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4329) Can't update alias attribute of host element from jboss-cli
by Kohei Nozaki (JIRA)
[ https://issues.jboss.org/browse/WFLY-4329?page=com.atlassian.jira.plugin.... ]
Kohei Nozaki updated WFLY-4329:
-------------------------------
Description:
UPDATE: sorry, I pasted wrong one of error.
I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
jboss-cli gives following error:
{code}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=www.example.com)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: null",
"rolled-back" => true
}
{code}
Stacktraces in WildFly console:
{code}
10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("host" => "default-host")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
was:
I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
jboss-cli gives following error:
{code}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=www.example.com)
{
"outcome" => "failed",
"failure-description" => "JBAS014792: Unknown attribute www.example.com",
"rolled-back" => true
}
{code}
Stacktraces in WildFly console:
{code}
10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("host" => "default-host")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
> Can't update alias attribute of host element from jboss-cli
> -----------------------------------------------------------
>
> Key: WFLY-4329
> URL: https://issues.jboss.org/browse/WFLY-4329
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK8u20
> Reporter: Kohei Nozaki
> Assignee: Stuart Douglas
>
> UPDATE: sorry, I pasted wrong one of error.
> I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
> jboss-cli gives following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=alias, value=www.example.com)
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> {code}
> Stacktraces in WildFly console:
> {code}
> 10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
> at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4329) Can't update alias attribute of host element from jboss-cli
by Kohei Nozaki (JIRA)
Kohei Nozaki created WFLY-4329:
----------------------------------
Summary: Can't update alias attribute of host element from jboss-cli
Key: WFLY-4329
URL: https://issues.jboss.org/browse/WFLY-4329
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Environment: Oracle JDK8u20
Reporter: Kohei Nozaki
Assignee: Stuart Douglas
I'm trying to create an another "server" with "host" element inside undertow subsystem with jboss-cli, but it produces an error and exception at writing attribute named "alias" of "host" element. I think it should be able to do with jboss-cli. or more descriptive error is required even if it is intended to.
jboss-cli gives following error:
{code}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=www.example.com)
{
"outcome" => "failed",
"failure-description" => "JBAS014792: Unknown attribute www.example.com",
"rolled-back" => true
}
{code}
Stacktraces in WildFly console:
{code}
10:11:57,397 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("host" => "default-host")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:132) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.ListAttributeDefinition.convertParameterExpressions(ListAttributeDefinition.java:328) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AttributeDefinition.validateAndSet(AttributeDefinition.java:438) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractWriteAttributeHandler.execute(AbstractWriteAttributeHandler.java:88) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:112) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:276) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_20]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_20]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3607) jsr356: OnError always called on page reload
by Melvin Williams (JIRA)
[ https://issues.jboss.org/browse/WFLY-3607?page=com.atlassian.jira.plugin.... ]
Melvin Williams commented on WFLY-3607:
---------------------------------------
Is there a workaround for this issue?
> jsr356: OnError always called on page reload
> --------------------------------------------
>
> Key: WFLY-3607
> URL: https://issues.jboss.org/browse/WFLY-3607
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 9.0.0.Alpha1
>
>
> When I reload (F5) with Chrome, any jsr356's Handler will be called with
> {noformat}
> 11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {noformat}
> Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by William Burns (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
William Burns commented on JGRP-1908:
-------------------------------------
A task was assumed to be idempotent to handle such cases (as mentioned by Bela on the forum). It should be doable to provide a way to control the policy though.
There are a few different ways I can think to do this.
# Add new overloaded methods to the interface that take the policy
# Check annotation or interface of the class of the instance provided
# Compose the ExecutionService in another Service that when constructing takes a Policy so that normal submit method can be used but all submitted instances will use the originally provided Policy
I am thinking the latter of the choices, WDYT?
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.2
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months