[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[JBoss JIRA] (WFCORE-5107) Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" capability
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5107?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-5107:
-------------------------------------
Description:
Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo.
RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" capability should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated.
For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo.
was:
Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo.
RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated.
For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo.
> Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" capability
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5107
> URL: https://issues.redhat.com/browse/WFCORE-5107
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo.
> RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" capability should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated.
> For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13814:
------------------------------------
Description:
Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides its method. So just implement this directly and drop the org.jboss.as.remoting dependency.
To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.)
was:
Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency.
To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.)
> Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13814
> URL: https://issues.redhat.com/browse/WFLY-13814
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides its method. So just implement this directly and drop the org.jboss.as.remoting dependency.
> To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13814:
-----------------------------------------
Based on the last comment I've changed this to a Bug.
> Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13814
> URL: https://issues.redhat.com/browse/WFLY-13814
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency.
> To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13814) Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13814?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13814:
------------------------------------
Issue Type: Bug (was: Enhancement)
> Drop messaging subsystem's HTTPUpgradeService's use of SimpleHttpUpgradeHandshake, drop dep on org.jboss.as.remoting
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13814
> URL: https://issues.redhat.com/browse/WFLY-13814
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Messaging's HTTPUpgradeService is importing org.jboss.as.remoting.SimpleHttpUpgradeHandshake but then overrides one of its two methods. The other method is less than 10 lines of code. So just implement this directly and drop the org.jboss.as.remoting dependency.
> To be fair, SimpleHttpUpgradeHandshake also includes a complex 'FlexBase64' inner class, but undertow-core provides the same class. HttpUpgradeHandshake itself is from undertow-core so there's no reason not to use the Undertow class. (The same is true in SimpleHttpUpgradeHandshake.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month