October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3393: ----------------------------------------- Description: This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. was: The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3393: ---------------------------------------------- [~brian.stansberry], I updated the description. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9508?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9508: --------------------------------- Fix Version/s: 12.0.0.Alpha1 > Drop mod_cluster transformers for model versions prior to EAP 6.4 > ----------------------------------------------------------------- > > Key: WFLY-9508 > URL: https://issues.jboss.org/browse/WFLY-9508 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 11.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3393: ------------------------------------------ Where is this 10 set? > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9508: ------------------------------------ Summary: Drop mod_cluster transformers for model versions prior to EAP 6.4 Key: WFLY-9508 URL: https://issues.jboss.org/browse/WFLY-9508 Project: WildFly Issue Type: Task Components: mod_cluster Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9508?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9508: --------------------------------- Affects Version/s: 11.0.0.Final > Drop mod_cluster transformers for model versions prior to EAP 6.4 > ----------------------------------------------------------------- > > Key: WFLY-9508 > URL: https://issues.jboss.org/browse/WFLY-9508 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 11.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-3393: -------------------------------------------- Summary: Connection Timeout should take into account time spent in opening the channel Key: WFCORE-3393 URL: https://issues.jboss.org/browse/WFCORE-3393 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Jean-Francois Denise Assignee: Brian Stansberry The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8767) Changing the max-pool-size of the datasource pool should indicate a "reload required" in the CLI output

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8767?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8767: ----------------------------------------------- Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1405954|https://bugzilla.redhat.com/show_bug.cgi?id=1405954] from ASSIGNED to POST > Changing the max-pool-size of the datasource pool should indicate a "reload required" in the CLI output > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-8767 > URL: https://issues.jboss.org/browse/WFLY-8767 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Lin Gao > Assignee: varsha Kamble > Labels: downstream_dependency > Original Estimate: 2 days > Remaining Estimate: 2 days > > In EAP domain mode, when changing the max-pool-size attribute of a datasource via CLI, the response does not indicate that a reload is required. However, reading the statistics of that datasource does not reflect the Available count as per the new max pool value until a restart of the server is performed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1429) Elytron policy is not validated for write-attribute operation

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/ELY-1429?page=com.atlassian.jira.plugin.s... ] Michal Petrov updated ELY-1429: ------------------------------- Description: Editing a policy using {{write-attribute}} simply propagates the changes without any checking, making the service fail on subsequent reload. (was: When creating new Elytron policy required fields are validated immediately after creation and if the validation fails, the policy is not added . However when editing already existing policy and supplying it with invalid values, no validation error is shown. See attachement.) > Elytron policy is not validated for write-attribute operation > ------------------------------------------------------------- > > Key: ELY-1429 > URL: https://issues.jboss.org/browse/ELY-1429 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Michal Petrov > > Editing a policy using {{write-attribute}} simply propagates the changes without any checking, making the service fail on subsequent reload. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1429) Elytron policy is not validated for write-attribute operation

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/ELY-1429?page=com.atlassian.jira.plugin.s... ] Michal Petrov moved JBEAP-13673 to ELY-1429: -------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1429 (was: JBEAP-13673) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) > Elytron policy is not validated for write-attribute operation > ------------------------------------------------------------- > > Key: ELY-1429 > URL: https://issues.jboss.org/browse/ELY-1429 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Michal Petrov > > When creating new Elytron policy required fields are validated immediately after creation and if the validation fails, the policy is not added . However when editing already existing policy and supplying it with invalid values, no validation error is shown. See attachement. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 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 October 2017