March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10009) Introduce a maximum-timeout management model attribute

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-10009?page=com.atlassian.jira.plugin... ] Amos Feng updated WFLY-10009: ----------------------------- Description: some resources may fail with a timeout value of Integer.MAX_VALUE for various reasons, so a lower "maximum" (such as one year) might be better. The purpose of the suggestion of the maximum timeout attribute would be to make this value configurable (also in the event where someone programmatically sets a timeout which might be problematic), > Introduce a maximum-timeout management model attribute > ------------------------------------------------------ > > Key: WFLY-10009 > URL: https://issues.jboss.org/browse/WFLY-10009 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > some resources may fail with a timeout value of Integer.MAX_VALUE for various reasons, so a lower "maximum" (such as one year) might be better. The purpose of the suggestion of the maximum timeout attribute would be to make this value configurable (also in the event where someone programmatically sets a timeout which might be problematic), -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10009) Introduce a maximum-timeout management model attribute

by Amos Feng (JIRA)

Amos Feng created WFLY-10009: -------------------------------- Summary: Introduce a maximum-timeout management model attribute Key: WFLY-10009 URL: https://issues.jboss.org/browse/WFLY-10009 Project: WildFly Issue Type: Enhancement Components: Transactions Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9877) NAKACK, UNICAST2 and MERGE2 need to translate to their newer variants

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-9877?page=com.atlassian.jira.plugin.... ] Petr Kremensky commented on WFLY-9877: -------------------------------------- I'll increasing the priority here as this would be a blocker for EAP and afaik we're not suppose to create JBEAP jiras for such an issues anymore. {noformat} # https://access.qa.redhat.com/documentation/en-us/red_hat_jboss_enterprise... WORKSPACE=`pwd` CONFIG=standalone-full-ha.xml unzip -q jboss-eap-6.4.19-full-build.zip cp -r ${WILDFLY}/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT . EAP6_HOME=${WORKSPACE}/jboss-eap-6.4 EAP7_HOME=${WORKSPACE}/wildfly-13.0.0.Alpha1-SNAPSHOT cp ${EAP6_HOME}/standalone/configuration/${CONFIG} ${EAP7_HOME}/standalone/configuration ${EAP7_HOME}/bin/standalone.sh -c ${CONFIG} --start-mode=admin-only & ${EAP7_HOME}/bin/jboss-cli.sh --connect --controller=remote://localhost:9999 /subsystem=jacorb:migrate /subsystem=messaging:migrate /subsystem=web:migrate /subsystem=cmp:remove /extension=org.jboss.as.cmp:remove /subsystem=jaxr:remove /extension=org.jboss.as.jaxr:remove /subsystem=threads:remove /extension=org.jboss.as.threads:remove reload ... 09:06:58,771 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 27) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "jgroups"), ("channel" => "ee-singleton") ]) - failure description: "WFLYCLJG0016: Unable to load protocol class org.jgroups.protocols.pbcast.NAKACK" 09:06:58,772 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem jgroups boot operations" 09:06:58,773 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem jgroups boot operations\"" 09:06:58,776 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. This works with non-ha profiles. {noformat} fyi: [~kabirkhan], [~jamezp] > NAKACK, UNICAST2 and MERGE2 need to translate to their newer variants > --------------------------------------------------------------------- > > Key: WFLY-9877 > URL: https://issues.jboss.org/browse/WFLY-9877 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Beta1 > Reporter: Richard Janík > Assignee: Paul Ferraro > > This is only an issue for EAP, which has different versions than WFLY, for that reason, all the versions mentioned here are EAP ones. > After some discussion with people who test migrations, we found that these protocols that were deprecated in JGroups 3.6.x present in 7.1.0 and were removed in JGroups 4.0.10 present in 7.2.0 should be brought back in some form: > {noformat} > NAKACK --> NAKACK2 > UNICAST2 --> UNICAST3 > MERGE2 --> MERGE3 > {noformat} > These are not in the default 7.0 or 7.1 configuration, so why do we need to translate these like we do it for NAKACK2? Because these protocols can be expected to be present in the 7.1 configuration due to migration from 6.x, where they are by default. Since, after migration from 6.x, these will work with the 7.1 configuration, and since there is a reason to expect them being used even if they are deprecated, we should not just silently remove these protocols with the JGroups upgrade that is in 7.2 - the configuration file from 7.1 should always work with 7.2. > Cc [~msvehla] [~pkremens] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9417) No default-response-code during deployment sent

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9417?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-9417: --------------------------------- Issue Type: Feature Request (was: Bug) > No default-response-code during deployment sent > ----------------------------------------------- > > Key: WFLY-9417 > URL: https://issues.jboss.org/browse/WFLY-9417 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 11.0.0.CR1 > Reporter: Nero M > Assignee: Stuart Douglas > Original Estimate: 1 week > Remaining Estimate: 1 week > > Hi, i am experiencing a strange behaviour with WF11 which was not like this on WF10. > When a *.dodeploy file exists during server-start. The Default response code > e.g. > <host name="default-host" alias="localhost" default-response-code="503"> > Is not sent during the time of deployment. Instead any requests goes into a pending state with (seemingly) no timeout. > If the *.dodeploy file is created AFTER the server boots up, the default response code is sent until the deployment is complete. > (After this line): WFLYSRV0025: WildFly Full 11.0.0.CR1 (WildFly Core 3.0.4.Final) started in 6468ms > I think the server should not "hang" during the deployment-time, just like it was on WF10. > Is there anything which has to be changed in the standalone xml between 10 and 11 to get the same behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9974) Remove unused 'basic-authType' complex type in wildfly-undertow xsd file

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFLY-9974?page=com.atlassian.jira.plugin.... ] Jan Stourac commented on WFLY-9974: ----------------------------------- [~swd847], I have just noticed, you have bumped undertow subsystem version to 6.0 recently in this [MR|https://github.com/wildfly/wildfly/pull/10866/commits/58da675db36aa7ea...]. Maybe it is a good time to resolve this issue now too? > Remove unused 'basic-authType' complex type in wildfly-undertow xsd file > ------------------------------------------------------------------------ > > Key: WFLY-9974 > URL: https://issues.jboss.org/browse/WFLY-9974 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 12.0.0.Final > Reporter: Jan Stourac > Assignee: Stuart Douglas > Priority: Minor > > Since undertow subsystem version 4.0, the [{{basic-authType}}|https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resources/schema/wildfly-undertow_5_0.xsd#L578-L580] has not been utilized anymore. We should probably remove that type definition from our xsd file with another subsystem version bump. > This type was used for {{basic-auth}} filter which is no longer present in undertow. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9417) No default-response-code during deployment sent

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9417?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-9417: -------------------------------------- For now the only real workaround is to start the server and then perform the deployment. I will add an option to make this configurable. > No default-response-code during deployment sent > ----------------------------------------------- > > Key: WFLY-9417 > URL: https://issues.jboss.org/browse/WFLY-9417 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.CR1 > Reporter: Nero M > Assignee: Stuart Douglas > Original Estimate: 1 week > Remaining Estimate: 1 week > > Hi, i am experiencing a strange behaviour with WF11 which was not like this on WF10. > When a *.dodeploy file exists during server-start. The Default response code > e.g. > <host name="default-host" alias="localhost" default-response-code="503"> > Is not sent during the time of deployment. Instead any requests goes into a pending state with (seemingly) no timeout. > If the *.dodeploy file is created AFTER the server boots up, the default response code is sent until the deployment is complete. > (After this line): WFLYSRV0025: WildFly Full 11.0.0.CR1 (WildFly Core 3.0.4.Final) started in 6468ms > I think the server should not "hang" during the deployment-time, just like it was on WF10. > Is there anything which has to be changed in the standalone xml between 10 and 11 to get the same behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10008) Dwm test cases fail intermittently

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-10008: ------------------------------------- Summary: Dwm test cases fail intermittently Key: WFLY-10008 URL: https://issues.jboss.org/browse/WFLY-10008 Project: WildFly Issue Type: Bug Components: Clustering, JCA Reporter: Stuart Douglas Assignee: Paul Ferraro Example run is at https://ci.wildfly.org/viewLog.html?buildId=94221&buildTypeId=WF_PullRequ... This appears to be a timeout issue with a cache taking too long to start. It seems to take 60s to start, but as the test only waits 60s it fails. For now I am going to work around this by increasing the timeout of the reload slightly, however this should be investigated and fixed Relevant part from the log of the server in manual mode (note jump in timestamps): {code} 2018-03-12 20:51:34,375 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) WFLYCLINF0002: Started org.infinispan.CONFIG cache from web container 2018-03-12 20:51:34,423 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 68) WFLYCLINF0002: Started client-mappings cache from ejb container 2018-03-12 20:52:34,082 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) WFLYCLINF0002: Started org.infinispan.CONFIG cache from hibernate container 2018-03-12 20:52:34,096 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "arquillian-service" (runtime-name : "arquillian-service") 2018-03-12 20:52:34,141 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10007) Module org.infinispan.cachestore.remote was dropped

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10007?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-10007: --------------------------------------- Not sure how relevant this is, but the remote cache store is being deprecated with WFLY-9860 in https://github.com/wildfly/wildfly/pull/10960. > Module org.infinispan.cachestore.remote was dropped > --------------------------------------------------- > > Key: WFLY-10007 > URL: https://issues.jboss.org/browse/WFLY-10007 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 13.0.0.Beta1 > > > The org.infinispan.cachestore.remote module was renamed to org.infinispan.persistence.remote as part of WFLY-8207 but the Keycloak adapters that integrate into WF depend on that module. So, proposal is to add an alias module. > The module was private but projects/products that layer on top of WF/EAP legitimately use private modules. Also, this isn't really a layer, it's an adapter to allow us to integrate with an external server, so we somewhat broke ourselves. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9999) Upgrade mod_cluster to 1.3.9.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9999?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9999: --------------------------------- Description: Changelog https://issues.jboss.org/projects/MODCLUSTER/versions/12335982 > Upgrade mod_cluster to 1.3.9.Final > ---------------------------------- > > Key: WFLY-9999 > URL: https://issues.jboss.org/browse/WFLY-9999 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 12.0.0.Final > Reporter: Panagiotis Sotiropoulos > Assignee: Radoslav Husar > Fix For: 13.0.0.Beta1 > > > Changelog > https://issues.jboss.org/projects/MODCLUSTER/versions/12335982 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9999) Upgrade mod_cluster to 1.3.9.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9999?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9999: --------------------------------- Fix Version/s: 13.0.0.Beta1 > Upgrade mod_cluster to 1.3.9.Final > ---------------------------------- > > Key: WFLY-9999 > URL: https://issues.jboss.org/browse/WFLY-9999 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 12.0.0.Final > Reporter: Panagiotis Sotiropoulos > Assignee: Radoslav Husar > Fix For: 13.0.0.Beta1 > > > Changelog > https://issues.jboss.org/projects/MODCLUSTER/versions/12335982 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 March 2018