[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13774:
------------------------------------
Component/s: Build System
> Difference in OpenTracing subsystem standard configuration leads to the tests failures
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-13774
> URL: https://issues.redhat.com/browse/WFLY-13774
> Project: WildFly
> Issue Type: Bug
> Components: Build System, MP OpenTracing
> Reporter: Sultan Zhantemirov
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger">
> <jaeger-tracer name="jaeger">
> <sampler-configuration sampler-type="const" sampler-param="1.0"/>
> </jaeger-tracer>
> </subsystem>
> {noformat}
> With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/>
> {noformat}
> As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests.
> A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves?
> Thank you.
> [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri...
> [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13808:
-----------------------------------------
This isn't a bug; it was deliberately done. Accepting requests over the network while the server is starting results in requests hitting incompletely started resources and getting random errors.
WFCORE-4291 is a Feature Request to add an ability to turn off this behavior; it sounds like you are looking for a similar thing.
There is no diff.patch attached. https://github.com/bstansberry/wildfly-core/tree/WFCORE-4291 is the work I did on it before I had to move away from it. If you have any suggestions they're welcome. I expect the issue will be resolved for WildFly 22.
> Make HTTP server available during deployment when starting up
> -------------------------------------------------------------
>
> Key: WFLY-13808
> URL: https://issues.redhat.com/browse/WFLY-13808
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 20.0.1.Final
> Reporter: Alojzij Blatnik
> Assignee: Brian Stansberry
> Priority: Major
>
> HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
> That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
> I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-13808.
-------------------------------------
Resolution: Duplicate Issue
> Make HTTP server available during deployment when starting up
> -------------------------------------------------------------
>
> Key: WFLY-13808
> URL: https://issues.redhat.com/browse/WFLY-13808
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 20.0.1.Final
> Reporter: Alojzij Blatnik
> Assignee: Brian Stansberry
> Priority: Major
>
> HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
> That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
> I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFLY-13774) Difference in OpenTracing subsystem standard configuration leads to the tests failures
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13774?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-13774:
---------------------------------------
Component/s: MP OpenTracing
(was: Build System)
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
> Difference in OpenTracing subsystem standard configuration leads to the tests failures
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-13774
> URL: https://issues.redhat.com/browse/WFLY-13774
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Reporter: Sultan Zhantemirov
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Since OpenTracing has been introduced, `standalone.xml` had the following OT SmallRye subsystem configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0" default-tracer="jaeger">
> <jaeger-tracer name="jaeger">
> <sampler-configuration sampler-type="const" sampler-param="1.0"/>
> </jaeger-tracer>
> </subsystem>
> {noformat}
> With WildFly 19 and later we also have `standalone-microprofile.xml` configuration file which is used by default in MicroProfile test suite [1]. It has the following configuration:
> {noformat}
> <subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:2.0"/>
> {noformat}
> As it is recommended in documentation [2] it's better to define missing Jaeger properties (_sampler type _and _sampler param_) in order to sample every request. Sampling every request is needed by MicroProfile test suite OpenTracing basic tests.
> A question is: will `standalone-microprofile.xml` configuration file have the wider OT subsystem configuration? Or do the tests have to define additional attributes in subsystem by themselves?
> Thank you.
> [1] - https://github.com/jboss-eap-qe/eap-microprofile-test-suite#target-distri...
> [2] - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-4291:
------------------------------------------
I don't expect this before WildFly 22.
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Brian Stansberry
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFLY-13805) Bind address of Wildfly cannot be passed with Eclipse Runtime
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13805?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13805:
-----------------------------------------
I don't see how this is a WildFly issue. Our standard configs let you use a generic java process configuration mechanism, -D, to let you set the bind address. If that somehow doesn't work in Eclipse that's an Eclipse issue.
If Eclipse isn't using our standalone.sh script to start the java process but is instead directly launching the JVM, as long as it either passes -Djboss.bind.address={{<IP>}} to the JVM launch or passes it as an arg to our main, it should work.
> Bind address of Wildfly cannot be passed with Eclipse Runtime
> -------------------------------------------------------------
>
> Key: WFLY-13805
> URL: https://issues.redhat.com/browse/WFLY-13805
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 18.0.1.Final
> Reporter: Andre Kreienbring
> Assignee: Brian Stansberry
> Priority: Major
>
> This solution
> [https://access.redhat.com/solutions/18664]
> says that one must pass the bind address with the start up command. And YES that works. But because neither adding
> {{{{<interface name="public">
> <inet-address value="${jboss.bind.address:<IP>}"/>}}}}
> {{{{}}{{ </interface>}}}}
> to standalone.xml
> nor passing -Djboss.bind.address={{{{<IP>}}}} in the Eclipse Launch Configuration (JAVA Options) works, I'm obviously not able to start the server with a specific bind address from Eclipse. It's only running on localhost and 127.0.0.1.
> This is annoying for example during the development of a mobile app. The server simply can't be reached when started with Eclipse.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFCORE-5092) Windows Service cannot be stopped when using custom JAVA_HOME path
by Walter Raaflaub (Jira)
[ https://issues.redhat.com/browse/WFCORE-5092?page=com.atlassian.jira.plug... ]
Walter Raaflaub commented on WFCORE-5092:
-----------------------------------------
my_keycloak_service-stderr.2020-08-30.log:
{code:java}
2020-08-30 11:08:21 Commons Daemon procrun stderr initialized
Das System kann den angegebenen Pfad nicht finden.
{code}
my_keycloak_service-stdout.2020-08-30.log:
{code:java}
...
11:09:29,046 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 11.0.1 (WildFly Core 12.0.3.Final) started in 66165ms - Started 588 of 886 services (601 services are lazy, passive or on-demand)
11:09:29,217 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
11:09:29,334 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
Drcken Sie eine beliebige Taste . . .{code}
> Windows Service cannot be stopped when using custom JAVA_HOME path
> ------------------------------------------------------------------
>
> Key: WFCORE-5092
> URL: https://issues.redhat.com/browse/WFCORE-5092
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Final
> Reporter: Walter Raaflaub
> Assignee: Lukas Vydra
> Priority: Major
>
> I am running keycloak in a Wildfly container as a Windows service on Windows Server 2019. The service starts up and works correctly; but it hangs when I try to stop it.
> There is no global JAVA_HOME environment variable defined on the server; I'm using a custom JAVA_HOME path that I have configured in standalone.conf.bat.
> While stopping, the service issues the following warning in stdout.log:
> {noformat}
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> Drcken Sie eine beliebige Taste . . .
> {noformat}
> (Drücken Sie eine beliebige Taste . . . = German vor "Press any key ...")
> It seems that when stopping the service, the JAVA_HOME setting is not correctly passed to the jboss-cli.bat script. The script seems to be waiting for user input, which is akward in a Windows service. That means that also the NOPAUSE setting is not passed correctly to the jboss-cli.bat script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFCORE-5092) Windows Service cannot be stopped when using custom JAVA_HOME path
by Walter Raaflaub (Jira)
[ https://issues.redhat.com/browse/WFCORE-5092?page=com.atlassian.jira.plug... ]
Walter Raaflaub edited comment on WFCORE-5092 at 8/30/20 5:37 AM:
------------------------------------------------------------------
[~lvydra]
Hi Lukas,
Thanks for looking into the issue!
In point 5 of the steps to reproduce, I register the Windows service using the "service.bat" script by Tom Fonteyne from the "docs\contrib\scripts\service" directory (after copying this directory to "bin"). That's probably the key issue. After understanding the above comment by Bernhard Roider, I looked into the script.
I registered the service as follows:
run cmd as admin, cd to bin\service directory, then execute:
{code:java}
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service"
{code}
When I register the service using the above command, it actually executes the following:
{code:java}
"D:\basedir\keycloak\bin\service\amd64\wildfly-service" install my_keycloak_service --DisplayName="my_keycloak_service" --Description="my keycloak service" --LogLevel=INFO --LogPath="D:\basedir\keycloak\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=auto --StartImage=cmd.exe --StartPath="D:\basedir\keycloak\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=D:\basedir\keycloak\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="D:\basedir\keycloak\bin" ++StopParams="/c jboss-cli.bat --connect --command=:shutdown" ++Environment=
{code}
Note that NOPAUSE=Y is added to the StartParams, but not to the StopParams.
When registered this way, the service behaves as described: it hangs when I try to stop it.
From Bernhard Roider's comment I concluded that I should have registered the service with the following command:
{code:java}
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service" /environment "NOPAUSE=Y;JAVA_HOME=D:\basedir\java\jdk11"
{code}
I wonder whether NOPAUSE=Y should be added to the StopParams expression, or the service.bat script should provide a default value for the environment parameter.
was (Author: wraaflaub):
[~lvydra]
Hi Lukas,
Thanks for looking into the issue!
In point 5 of the steps to reproduce, I register the Windows service using the "service.bat" script by Tom Fonteyne from the "docs\contrib\scripts\service" directory (after copying this directory to "bin"). That's probably the key issue. After understanding the above comment by Bernhard Roider, I looked into the script.
I registered the service as follows:
run cmd as admin, cd to bin\service directory, then execute:
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service"
When I register the service using the above command, it actually executes the following:
"D:\basedir\keycloak\bin\service\amd64\wildfly-service" install my_keycloak_service --DisplayName="my_keycloak_service" --Description="my keycloak service" --LogLevel=INFO --LogPath="D:\basedir\keycloak\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=auto --StartImage=cmd.exe --StartPath="D:\basedir\keycloak\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=D:\basedir\keycloak\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="D:\basedir\keycloak\bin" ++StopParams="/c jboss-cli.bat --connect --command=:shutdown" ++Environment=
Note that NOPAUSE=Y is added to the StartParams, but not to the StopParams.
When registered this way, the service behaves as described: it hangs when I try to stop it.
From Bernhard Roider's comment I concluded that I should have registered the service with the following command:
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service" /environment "NOPAUSE=Y;JAVA_HOME=D:\basedir\java\jdk11"
I wonder whether NOPAUSE=Y should be added to the StopParams expression, or the service.bat script should provide a default value for the environment parameter.
> Windows Service cannot be stopped when using custom JAVA_HOME path
> ------------------------------------------------------------------
>
> Key: WFCORE-5092
> URL: https://issues.redhat.com/browse/WFCORE-5092
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Final
> Reporter: Walter Raaflaub
> Assignee: Lukas Vydra
> Priority: Major
>
> I am running keycloak in a Wildfly container as a Windows service on Windows Server 2019. The service starts up and works correctly; but it hangs when I try to stop it.
> There is no global JAVA_HOME environment variable defined on the server; I'm using a custom JAVA_HOME path that I have configured in standalone.conf.bat.
> While stopping, the service issues the following warning in stdout.log:
> {noformat}
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> Drcken Sie eine beliebige Taste . . .
> {noformat}
> (Drücken Sie eine beliebige Taste . . . = German vor "Press any key ...")
> It seems that when stopping the service, the JAVA_HOME setting is not correctly passed to the jboss-cli.bat script. The script seems to be waiting for user input, which is akward in a Windows service. That means that also the NOPAUSE setting is not passed correctly to the jboss-cli.bat script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFCORE-5092) Windows Service cannot be stopped when using custom JAVA_HOME path
by Walter Raaflaub (Jira)
[ https://issues.redhat.com/browse/WFCORE-5092?page=com.atlassian.jira.plug... ]
Walter Raaflaub commented on WFCORE-5092:
-----------------------------------------
[~lvydra]
Hi Lukas,
Thanks for looking into the issue!
In point 5 of the steps to reproduce, I register the Windows service using the "service.bat" script by Tom Fonteyne from the "docs\contrib\scripts\service" directory (after copying this directory to "bin"). That's probably the key issue. After understanding the above comment by Bernhard Roider, I looked into the script.
I registered the service as follows:
run cmd as admin, cd to bin\service directory, then execute:
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service"
When I register the service using the above command, it actually executes the following:
"D:\basedir\keycloak\bin\service\amd64\wildfly-service" install my_keycloak_service --DisplayName="my_keycloak_service" --Description="my keycloak service" --LogLevel=INFO --LogPath="D:\basedir\keycloak\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=auto --StartImage=cmd.exe --StartPath="D:\basedir\keycloak\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=D:\basedir\keycloak\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="D:\basedir\keycloak\bin" ++StopParams="/c jboss-cli.bat --connect --command=:shutdown" ++Environment=
Note that NOPAUSE=Y is added to the StartParams, but not to the StopParams.
When registered this way, the service behaves as described: it hangs when I try to stop it.
From Bernhard Roider's comment I concluded that I should have registered the service with the following command:
service install /startup /name my_keycloak_service /display my_keycloak_service /desc "my keycloak service" /environment "NOPAUSE=Y;JAVA_HOME=D:\basedir\java\jdk11"
I wonder whether NOPAUSE=Y should be added to the StopParams expression, or the service.bat script should provide a default value for the environment parameter.
> Windows Service cannot be stopped when using custom JAVA_HOME path
> ------------------------------------------------------------------
>
> Key: WFCORE-5092
> URL: https://issues.redhat.com/browse/WFCORE-5092
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Final
> Reporter: Walter Raaflaub
> Assignee: Lukas Vydra
> Priority: Major
>
> I am running keycloak in a Wildfly container as a Windows service on Windows Server 2019. The service starts up and works correctly; but it hangs when I try to stop it.
> There is no global JAVA_HOME environment variable defined on the server; I'm using a custom JAVA_HOME path that I have configured in standalone.conf.bat.
> While stopping, the service issues the following warning in stdout.log:
> {noformat}
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> Drcken Sie eine beliebige Taste . . .
> {noformat}
> (Drücken Sie eine beliebige Taste . . . = German vor "Press any key ...")
> It seems that when stopping the service, the JAVA_HOME setting is not correctly passed to the jboss-cli.bat script. The script seems to be waiting for user input, which is akward in a Windows service. That means that also the NOPAUSE setting is not passed correctly to the jboss-cli.bat script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months