April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8490) NO AJP listenening socket when setting IP with -Djboss.bind.address=XX -Djboss.bind.address.management=XX

by Gaétan QUENTIN (JIRA)

Gaétan QUENTIN created WFLY-8490: ------------------------------------ Summary: NO AJP listenening socket when setting IP with -Djboss.bind.address=XX -Djboss.bind.address.management=XX Key: WFLY-8490 URL: https://issues.jboss.org/browse/WFLY-8490 Project: WildFly Issue Type: Bug Components: ConfigAdmin Affects Versions: 10.1.0.Final Environment: ubuntu 16.04 Reporter: Gaétan QUENTIN Assignee: Thomas Diesler When launching WFLY with ./standalone.sh --server-config=standalone-full.xml without bind address parameter, ajplistener is well launch on ip 127.0.0.1 when binding ip adress , ajp listener disappears: ./standalone.sh --server-config=standalone-full.xml -Djboss.bind.address=172.20.12.192 -Djboss.bind.address.management=172.20.12.192& nothing is listenting on port 8009 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8489) Undertow configuration in default profiles references Elytron

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8489?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-10072 to WFLY-8489: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8489 (was: JBEAP-10072) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR13) > Undertow configuration in default profiles references Elytron > ------------------------------------------------------------- > > Key: WFLY-8489 > URL: https://issues.jboss.org/browse/WFLY-8489 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > Current server profiles breaks requirements in EAP7-543. > The Elytron subsystem is referenced from the Undertow one - namely the {{/subsystem=undertow/server=default-server/host=default-host/setting=http-invoker}} references the {{/subsystem=elytron/http-authentication-factory=application-http-authentication}}. > Related RFE EAP7-543 says in its Description: > {quote} > ... add the Elytron subsystem ready to be used but not actually used ... > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-8466. ---------------------------------- Resolution: Out of Date > Socket leak when setting HTTP Content-Length and client not reading entire response > ----------------------------------------------------------------------------------- > > Key: WFLY-8466 > URL: https://issues.jboss.org/browse/WFLY-8466 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: CentOS 6.7 > Reporter: Johannes Ritter > Assignee: Stuart Douglas > Labels: leak, socket > Attachments: socket_leak.tar.gz > > > Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set. > The leaked sockets can be determined by "lsof -p <process-id> | grep identify". The relevant sockets are listed with "Can't identify protocol". > The leak occurs if the client connection is closed (on the client side) before the server could send the complete response. > It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click. > *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2380) JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2380?page=com.atlassian.jira.plugi... ] Jan Kalina edited comment on WFCORE-2380 at 4/2/17 3:36 AM: ------------------------------------------------------------ Adding configurable-sasl-server-factory necessary, or trying individual mechanisms exceeds 8 allowed authentication attemps: {code:xml} <configurable-sasl-server-factory name="elytronConfigurableSasl" sasl-server-factory="global"> <filters> <filter> <pattern-filter value="PLAIN"/> </filter> </filters> </configurable-sasl-server-factory> {code} Only considerable improvement could be automatic filtering in sasl-authentication-factory by configured mechanisms - but *mechanism-name* is optional here, so it would work only when it would be specified for all *<mechanism>*. [~dlofthouse] What do you thing about solution using automatic filtering when mechanism-name for all configurations specified? was (Author: honza889): Adding configurable-sasl-server-factory necessary, or individual mechanism exceeds 8 allowed authentication attemps: {code:xml} <configurable-sasl-server-factory name="elytronConfigurableSasl" sasl-server-factory="global"> <filters> <filter> <pattern-filter value="PLAIN"/> </filter> </filters> </configurable-sasl-server-factory> {code} Only considerable improvement could be automatic filtering in sasl-authentication-factory by configured mechanisms - but mechanism name is optional here, so it would work only when it would be specified for all <mechanism>. > JBoss CLI is not able to connect to interface secured by Elytron SASL factories with PLAIN mechanism > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2380 > URL: https://issues.jboss.org/browse/WFCORE-2380 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In case when PLAIN mechanism is used for Elytron SASL factories used by any of management-interfaces then JBoss CLI is not able to connect to the server. This issue happens with http-interface as well as native-interface. See Steps to Reproduce for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2612) Upgrade WildFly Common to 1.2.0.Beta9

by David Lloyd (JIRA)

David Lloyd created WFCORE-2612: ----------------------------------- Summary: Upgrade WildFly Common to 1.2.0.Beta9 Key: WFCORE-2612 URL: https://issues.jboss.org/browse/WFCORE-2612 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Beta13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2611) Upgrade WildFly Client Config to 1.0.0.Beta3

by David Lloyd (JIRA)

David Lloyd created WFCORE-2611: ----------------------------------- Summary: Upgrade WildFly Client Config to 1.0.0.Beta3 Key: WFCORE-2611 URL: https://issues.jboss.org/browse/WFCORE-2611 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Beta13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2610) Upgrade XNIO to 3.5.0.Beta4

by David Lloyd (JIRA)

David Lloyd created WFCORE-2610: ----------------------------------- Summary: Upgrade XNIO to 3.5.0.Beta4 Key: WFCORE-2610 URL: https://issues.jboss.org/browse/WFCORE-2610 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Beta13 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2609) CLIRolloutPlanTestCase hang

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2609: ---------------------------------------- Summary: CLIRolloutPlanTestCase hang Key: WFCORE-2609 URL: https://issues.jboss.org/browse/WFCORE-2609 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Reporter: Brian Stansberry Priority: Critical Fix For: 3.0.0.Beta13 Hang: https://ci.wildfly.org/viewLog.html?buildId=53176&buildTypeId=WF_MasterWi... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-8488: -------------------------------------- [~meetoblivion] Can you reproduce on master? Did you set the datasource reference on JDBC_PING protocol resource? e.g. /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(data-source=ExampleDS) If that still fails, can you post configuration and stack trace? > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by John Ament (JIRA)

John Ament created WFLY-8488: -------------------------------- Summary: Usage of JGroups JDBC_PING attempts to delete row too late Key: WFLY-8488 URL: https://issues.jboss.org/browse/WFLY-8488 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: John Ament Assignee: Paul Ferraro I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 April 2017