[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2056:
---------------------------
Attachment: (was: bla.java)
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2056:
--------------------------------
Latency for members A and B in the same JVM is ~60us for regular messages (JChannel) (bla) and 3-4us higher for MessageDispatcher (bla2).
Using {{SenderSendsBundler}}, the numbers drop to 42us (bla) and 47us (bla2).
RoundTrip shows RTT times (A and B are 2 processes on the same box) of 102us ({{TransferQueueBundler}}) and 83us ({{SenderSendsBundler}}), which is about twice the latency, which is OK.
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7266) BOM wildfly-javaee7-with-tools mismanages some dependencies
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-7266:
-----------------------------------
We do publish it, as it is needed for testing EE7 compatibility, but not really something end user apps would need to depend upon.
Well, they can, but you get all EE7 APIs at once, not just ones you need.
It could be that we only started doing boms around WF8 times.
> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
> Key: WFLY-7266
> URL: https://issues.jboss.org/browse/WFLY-7266
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
> Reporter: kostd kostd
> Assignee: Tomaz Cerar
> Priority: Optional
> Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.wildfly.bom</groupId>
> <artifactId>wildfly-javaee7-with-tools</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <dependencies>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-spec-api</artifactId>
> <version>10.1.0.Final</version>
> <type>pom</type>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO] +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO] +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] | \- javax.inject:javax.inject:jar:1:provided
> [INFO] +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO] +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO] +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO] +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO] +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO] +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO] | \- javax.activation:activation:jar:1.1.1:provided
> [INFO] +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO] +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO] +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
> <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
> <!-- BOM imports -->
> <!-- JBoss distributes a complete set of Java EE 7 APIs including
> a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
> a collection) of artifacts. We use this here so that we always get the correct
> versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
> this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
> this stack with any version of WildFly that implements Java EE 7! -->
> <dependency>
> <groupId>org.jboss.spec</groupId>
> <artifactId>jboss-javaee-7.0</artifactId>
> <version>${version.org.jboss.spec.jboss.javaee.7}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
> <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
> <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.el</groupId>
> <artifactId>jboss-el-api_3.0_spec</artifactId>
> <version>${version.org.jboss.spec.javax.el}</version>
> </dependency>
> ...
> <dependency>
> <groupId>org.jboss.spec.javax.faces</groupId>
> <artifactId>jboss-jsf-api_2.2_spec</artifactId>
> <version>${version.org.jboss.spec.javax.faces}</version>
> </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5239:
--------------------------------------
Well that's rather unfortunate situation, since this is the only test case, I'm aware of, included in standard execution (-DallTests) which requires 4 nodes to pass - only servers in Perf and Messaging lab have these four configured (+ maybe some exceptions in mwqe lab). I'll see what can be done on our side to workaround this.
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar &#27;[0m&#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &#27;[0mExecuted HTTP request
> &#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &#27;[0m&#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7273:
-------------------------------
Description:
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
Exception in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "ldap")
]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
{code}
was:
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7273:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7273:
----------------------------------
Summary: Adding ldap-realm in Elytron sometimes register capability even if add operation failed
Key: WFLY-7273
URL: https://issues.jboss.org/browse/WFLY-7273
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Reporter: Ondrej Lukas
Assignee: Brian Stansberry
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.2
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Gail Badner updated WFLY-6854:
------------------------------
Summary: Upgrade Hibernate ORM to 5.1.2 (was: Upgrade Hibernate ORM to 5.1.1)
> Upgrade Hibernate ORM to 5.1.2
> ------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7272) Elytron attribute-mapping index validation
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7272?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7272:
-----------------------------------
Assignee: Ilia Vassilev
> Elytron attribute-mapping index validation
> ------------------------------------------
>
> Key: WFLY-7272
> URL: https://issues.jboss.org/browse/WFLY-7272
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> To be consistent with other *-index attributes in jdbc-realm. Please, introduce model validation for attribute {{index}} of {{attribute-mapping}} element, as valid values are 1..maxint . Such validation could be useful also in elytron project, as elytron can be used without subsystem.
> Elytron subsystem allows to user to set value 0. Such configured jdbc-realm throws error in runtime.
> {code}
> 17:15:44,546 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/index.jsp: java.lang.RuntimeException: ELY01052: Unexpected error when processing authentication query "SELECT password,roles FROM test.wildfly_users WHERE username=?"
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:264)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$getIdentity$2(JdbcSecurityRealm.java:202)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.getIdentity(JdbcSecurityRealm.java:224)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.exists(JdbcSecurityRealm.java:188)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1583)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1608)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:466)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:461)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:724)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:85)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:215)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$1(JdbcSecurityRealm.java:207)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:259)
> ... 53 more
> Caused by: org.postgresql.util.PSQLException: The column index is out of range: 0, number of columns: 2.
> at org.postgresql.jdbc.PgResultSet.checkColumnIndex(PgResultSet.java:2754)
> at org.postgresql.jdbc.PgResultSet.checkResultSet(PgResultSet.java:2774)
> at org.postgresql.jdbc.PgResultSet.getString(PgResultSet.java:1881)
> at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1954)
> at org.wildfly.security.auth.realm.jdbc.mapper.AttributeMapper.map(AttributeMapper.java:40)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:209)
> ... 56 more
> {code}
> Also, there is wrong exception message "ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]" . Apparently should be "Jdbc realm".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months