May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12056) Standalone EJB Client using Remote UserTransaction can hang if there are more than 15 concurrent client threads

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-12056?page=com.atlassian.jira.plugin... ] Flavia Rainone reassigned WFLY-12056: ------------------------------------- Assignee: Flavia Rainone (was: Cheng Fang) > Standalone EJB Client using Remote UserTransaction can hang if there are more than 15 concurrent client threads > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12056 > URL: https://issues.jboss.org/browse/WFLY-12056 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > > Standalone EJB Client using Remote UserTransaction can hang if there are more than 15 concurrent client threads -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9482) ejb remote client hangs on undertow default worker pool exhaustion

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-9482?page=com.atlassian.jira.plugin.... ] Flavia Rainone reassigned WFLY-9482: ------------------------------------ Assignee: Flavia Rainone > ejb remote client hangs on undertow default worker pool exhaustion > ------------------------------------------------------------------ > > Key: WFLY-9482 > URL: https://issues.jboss.org/browse/WFLY-9482 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.1.0.Final > Reporter: Igor Vagulin > Assignee: Flavia Rainone > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1805) Remove wildfly-elytron-titan module from project

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1805: ------------------------------------- Summary: Remove wildfly-elytron-titan module from project Key: ELY-1805 URL: https://issues.jboss.org/browse/ELY-1805 Project: WildFly Elytron Issue Type: Bug Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.9.0.CR6 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12050) WildFly management console fails to load deployments if war fails to deploy

by Philippe Julien (Jira)

[ https://issues.jboss.org/browse/WFLY-12050?page=com.atlassian.jira.plugin... ] Philippe Julien commented on WFLY-12050: ---------------------------------------- [~brian.stansberry] I tried your likely fix but unfortunately there is still an exception with a slightly different stack trace. {noformat} 10:34:02.275 [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("read-attribute") failed - address: ([ ("deployment" => "test-war.war"), ("subsystem" => "undertow"), ("servlet" => "com.test.TestServlet") ]): java.lang.IllegalStateException at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50) at org.wildfly.extension.undertow.DeploymentServletDefinition$5$1.execute(DeploymentServletDefinition.java:138) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423) at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212) at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72) at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93) at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313) at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485) {noformat} I guess you also need to add the "|| deploymentServiceController.getState() != ServiceController.State.UP" in the other condition. > WildFly management console fails to load deployments if war fails to deploy > --------------------------------------------------------------------------- > > Key: WFLY-12050 > URL: https://issues.jboss.org/browse/WFLY-12050 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 16.0.0.Final > Reporter: Philippe Julien > Assignee: Flavia Rainone > Priority: Major > Attachments: Screen Shot 2019-05-06 at 10.37.03 AM.png > > > When a .war that has servlets declared using @WebServlet fails to deploy, the console cannot list any deployments. > Here is the exception that is logged by WildFly: > {noformat} > 09:52:08.629 [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("deployment" => "test-war.war"), > ("subsystem" => "undertow"), > ("servlet" => "com.test.TestServlet") > ]): java.lang.IllegalStateException > at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50) > at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler$1.execute(DeploymentServletDefinition.java:175) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212) > at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72) > at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93) > at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61) > at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {noformat} > I have pushed a small reproducer .war application here: https://github.com/philippejulien/test-war -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12055) Update jboss-ejb-client to 4.0.18

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12055: ------------------------------------- Summary: Update jboss-ejb-client to 4.0.18 Key: WFLY-12055 URL: https://issues.jboss.org/browse/WFLY-12055 Project: WildFly Issue Type: Component Upgrade Reporter: Tomasz Adamski Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1762) Ensure JAPICMP Compatibility and enable plug-in for all builds.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1762?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1762. ----------------------------------- Resolution: Done > Ensure JAPICMP Compatibility and enable plug-in for all builds. > --------------------------------------------------------------- > > Key: ELY-1762 > URL: https://issues.jboss.org/browse/ELY-1762 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.9.0.CR6 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12019) Cannot remove a undertow server resource at one time

by Bartosz Spyrko (Jira)

[ https://issues.jboss.org/browse/WFLY-12019?page=com.atlassian.jira.plugin... ] Bartosz Spyrko commented on WFLY-12019: --------------------------------------- [~brian.stansberry] as far as I can tell, once the WFCORE-4462 and WFLY-12047 are fixed, the whole resource tree under Host should be supporting allow-resource-service-restart and have restartLevel of RESTART_RESOURCE_SERVICES, so that should address the original issue. I guess the HostRemove should check if resource restart is allowed before removing services - apart from there is there any further improvement that should be made? Is that an acceptable solution or should the host remove operation be changed to ReloadRequiredRemoveStepHandler like you mentioned? > Cannot remove a undertow server resource at one time > ---------------------------------------------------- > > Key: WFLY-12019 > URL: https://issues.jboss.org/browse/WFLY-12019 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 16.0.0.Final > Reporter: Bartosz Spyrko > Assignee: Bartosz Spyrko > Priority: Major > > Cannot remove a server attribute. > {noformat} > [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:remove() > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.undertow.server.default-server.default-host was depended upon by service jboss.undertow.server.default-server.default-host.filter-ref.x-powered-by-header, service jboss.undertow.server.default-server.default-host.location. > /, service jboss.undertow.server.default-server.default-host.filter-ref.server-header", > "rolled-back" => true, > "response-headers" => undefined > } > {noformat} > However, it can be removed executing same command again. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ] Daniele Zonca commented on DROOLS-3731: --------------------------------------- [~uxdlc] To be honest I prefer the popover version for the errors that are strictly related to a node because I think it is easier to understand especially with large models. I mean error like "Decision A doesn't match because expected value is ABC while actual is XYZ". For general error (i.e. alert panel) I like the proposal > DMN UX - More info overlaid on models. > -------------------------------------- > > Key: DROOLS-3731 > URL: https://issues.jboss.org/browse/DROOLS-3731 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Test-error.png, Test-errorB.png, download (1).png, download.png > > > As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression. > Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2343) Change in IPv4 versus IPv6 picking algorithm

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2343?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2343 at 5/8/19 7:59 AM: -------------------------------------------------------- Below is the new algorithm for resolving IP addresses. What needs to be resolved is: * Symbolic addresses such as {{site_local}}, {{global}} etc * Symbolic names, e.g. {{belasmac}}, {{www.google.com}} * Regexps such as {{match-interface}}, {{match-host}} etc All of these can only be resolved once we know what type of addresses we need to provide. E.g. when {{UDP.bind_addr}} is {{127.0.0.1}}, {{site_local}} would have to be an IPv4 address. When {{bind_addr}} is {{::1}}, {{site_local}} needs to pick an IPv6 address. h4. Only IPv4 stack is available * IPv4 addresses are created by default (e.g. by {{InetAddress.getByName()}}, or {{site_local}}) * When an IPv6 address is defined in a configuration, an exception is thrown and the stack will not start h4. Only IPv6 stack is available * IPv6 addresses are created by default * When an IPv4 address is created, convert it to an IPv6-mapped address (default behavior) h4. Both IPv4 and IPv6 stacks are available (dual stack) * If {{java.net.preferIPv4Stack=true}} and {{java.net.preferIPv6Addresses=false}}: ** Assign IPv4 addresses by default ** When an IPv6 address is encountered, throw an exception and don't start the stack * If {{java.net.preferIPv6Addresses=true}} and {{java.net.preferIPv4Stack=false}}: ** Assign IPv6 addresses by default ** When an IPv4 address is encountered, convert it to an IPv6-mapped address (default behavior) * Both {{java.net.preferIPv4Stack}} and {{java.net.preferIPv6Addresses}} are set, or none are set ** The JDK's preference is to assign IPv4 addresses ** If we have a single IPv6 address (dotted-decimal or symbolic name resolved to IPv6) in the configuration -> Assign IPv6 addresses ** Otherwise -> use IPv4 addresses For dual stacks (both IPv4 and IPv6 stack is available in the JDK), these changes allow JGroups to run different configurations in the same JVM, e.g. one channel joining an IPv4 cluster, and another one joining an IPv6 cluster. was (Author: belaban): This is the new algorithm: h4. Only IPv4 stack is available * IPv4 addresses are created by default (e.g. by {{InetAddress.getByName()}}, or {{site_local}}) * When an IPv6 address is defined in a configuration, an exception is thrown and the stack will not start h4. Only IPv6 stack is available * IPv6 addresses are created by default * When an IPv4 address is created, convert it to an IPv6-mapped address (default behavior) h4. Both IPv4 and IPv6 stacks are available (dual stack) * If {{java.net.preferIPv4Stack=true}} and {{java.net.preferIPv6Addresses=false}}: ** Assign IPv4 addresses by default ** When an IPv6 address is encountered, throw an exception and don't start the stack * If {{java.net.preferIPv6Addresses=true}} and {{java.net.preferIPv4Stack=false}}: ** Assign IPv6 addresses by default ** When an IPv4 address is encountered, convert it to an IPv6-mapped address (default behavior) * Both {{java.net.preferIPv4Stack}} and {{java.net.preferIPv6Addresses}} are set, or none are set ** The JDK's preference is to assign IPv4 addresses ** If we have a single IPv6 address (dotted-decimal or symbolic name resolved to IPv6) in the configuration -> Assign IPv6 addresses ** Otherwise -> use IPv4 addresses For dual stacks (both IPv4 and IPv6 stack is available in the JDK), these changes allow JGroups to run different configurations in the same JVM, e.g. one channel joining an IPv4 cluster, and another one joining an IPv6 cluster. > Change in IPv4 versus IPv6 picking algorithm > -------------------------------------------- > > Key: JGRP-2343 > URL: https://issues.jboss.org/browse/JGRP-2343 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.0 > > > When https://issues.jboss.org/browse/JGRP-2305 was implemented, IPv4 was favored unless {{java.net.preferIPv6Addresses}} was set. > However, this makes the following case fail: no {{java.net.preferXXX}} option is set and the configuration contains one or more IPv6 addresses, e.g. {{UDP bind_addr="::1"}}. > This will fail, as the new algorithm sets the stack type as IPv4 (it works when {{java.net.preferIPv6Addresses}} is set). > Change: > * Look at all IP addresses in a configuration > * If all addresses are IPv6 and the stack type is IPv4 (and IPv6 is available) -> switch to IPv6 as stack type > * If all addresses are IPv4 and the stack type is IPv6 (and IPv4 is available) -> switch to IPv4 stack type -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1804) Support loading attributes from multiple security realms

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1804: ------------------------------------- Summary: Support loading attributes from multiple security realms Key: ELY-1804 URL: https://issues.jboss.org/browse/ELY-1804 Project: WildFly Elytron Issue Type: Feature Request Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.9.0.CR6 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2019