Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Deployment/Start Appears to Timeout After 2 Minutes #587

Closed
bubnick opened this issue Jul 15, 2020 · 20 comments
Closed

Server Deployment/Start Appears to Timeout After 2 Minutes #587

bubnick opened this issue Jul 15, 2020 · 20 comments

Comments

@bubnick
Copy link

bubnick commented Jul 15, 2020

Good Day,

I've recently run into a problem with my VSCode Server Extension when trying to deploy to a Wildfly 11.0 instance under JDK 8. (I have also tried using WildFly 19.1 with JDK 11 to no avail).

It seems no matter what I do, when attempting to launch the server via the VSCode extension, the server will startup as normal, but at around 2 minutes each time, the process abruptly stops and the server changes from "Starting" to "Stopped'.

The odd thing about this is I do not run into the issue when launching Wildfly from the various standalone.bat/.sh scripts.

Is there a configuration for timeout I am missing somewhere? I have searched the standalone.xml and cranked any potential waits/timeout values, but am still experiencing the same results. While not essential, it is nice being able to quickly attach a debugger directly through VSCode :)

Please let me know if you require logs or any other information.

@bubnick bubnick changed the title Server Deployment Appears to Timeout After 2 Minutes Server Deployment/Start Appears to Timeout After 2 Minutes Jul 15, 2020
@robstryker
Copy link
Collaborator

Looking at the codebase for the rsp, it seems we do have a 2 minute timeout for recognizing the server is started. And at this time we don't have a setting to override that. So your issue is a real one, and a bit unfortunate that I didn't consider adding a setting to override that.

I'm going on time-off for the next 5 weeks, so I won't be able to fix this until I get back unfortunately. But I just wanted to give you the peace of mind in at least knowing that this is a real issue, someone has looked into it, and it's a feature that should be expanded for our users.

@robstryker
Copy link
Collaborator

Moving this issue to rsp-server where the timeout is enforced.

@robstryker robstryker transferred this issue from redhat-developer/vscode-rsp-ui Jul 17, 2020
@robstryker
Copy link
Collaborator

Without prying, can you explain why your WF takes more than 2 minutes to start up? Is it that you're debugging the startup process? Or do you have some large deployments that delay the complete startup of the app server?

@bubnick
Copy link
Author

bubnick commented Jul 17, 2020

Thanks @robstryker! I was actually doing some more investigating into why we were hitting this timeout all of a sudden, and it looks like there may have been some policy changes to the enterprise AV my company uses. I am currently working with them to whitelist the relevant directories, so that should hopefully bring or deployment time down.

The app I support is quite large, so deployment usually takes some and that can affect the startup process.

Couple quick questions:

  1. Is this 2-minute timeout something that is just in the VSCode extension? Or does it just happen to be hitting it when running from standalone.bat does not.
  2. Is the timeout something that I could potentially remove/adjust with a fork for the time being? It isn't a critical requirement for us at this time, but I do miss having quick access to a debugger :)

@robstryker
Copy link
Collaborator

The two-minute timeout is in the RSP server, which is a standalone process that the vscode extension uses to start / stop / deploy to wildfly. I don't think it'd be easy to fork since you'd need to be able to build the rsp and the extension. I'd give you some steps (or actually fix the bug) but I'm on PTO right now. Sorry.

@bubnick
Copy link
Author

bubnick commented Aug 10, 2020

No worries!! Hopefully you are enjoying your PTO :). I was thinking if it was a relatively easy fork/fix it could be done as a temporary workaround, but that is not a problem

@ghost
Copy link

ghost commented Aug 24, 2020

Back from PTO. Will add timeout overrides for users once I get settled. :D

@ghost
Copy link

ghost commented Aug 26, 2020

https://github.com/robstryker/rsp-server/tree/serverTimeoutOverrides

Will merge once I regain access to my damn github. Ugh.

@bubnick
Copy link
Author

bubnick commented Aug 28, 2020

Hah, no worries! Thanks for the quick fix Rob! Greatly appreciated :)

As an aside, we were able to confirm that some changes to the company AV software was causing it to be overly aggressive on scanning the deploy folder as it was creating the temporary files. So it seems to be a combination of a large project and the AV software caused us to just barely bump up against the 2 minute timeout

@bubnick
Copy link
Author

bubnick commented Sep 10, 2020

Hi Rob! Just wondering if you had any luck recovering your account?

@robstryker
Copy link
Collaborator

This was fixed here: #596

Still no extension release. Working on it. Closing this issue since it's committed

@bubnick
Copy link
Author

bubnick commented Sep 15, 2020

Thanks Rob!

@fabioemoutinho
Copy link

fabioemoutinho commented Jan 27, 2021

18:29:20,199 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 6.0.11.Final-redhat-00001) iniciado em 46698ms - Iniciado 838 de serviços 1036 (os serviços 357 são lazy, passivos ou em demanda)

@robstryker jboss starts but red hat server connector stays in "starting". after 2 minutes it stops server.
what should I do?
Current default config:
"server.timeout.shutdown": "120000",
"server.timeout.startup": "120000",

EDIT:
changing defaults to 0 seems to have fixed it for me.

@robstryker
Copy link
Collaborator

Once the server process is launched, we use a web-port polling mechanism, ie, we go to localhost:8080 or whatever other port is expected, and wait for a response.

If your server is stuck in 'starting...' mode, you will want to check that its reachable by browser at the expected url. If you have changed the binding host or port, then you need to update various properties in the server adapter so that the tool knows where to look for a running server.

@VitalyVaryvdin
Copy link

Happens on my end with Wildfly 25
jboss.server.host & jboss.server.port are correctly set to localhost:8080 which I can access via browser

@jcrben
Copy link

jcrben commented Feb 3, 2023

UPDATE: seems like I was probably mistaken, but "server.timeout.startup": "120000" as recommended by redhat-developer/vscode-server-connector#468 (comment) worked

......
@robstryker I saw that a release was deployed, but I ran into a similar issue of timeouts when using https://github.com/redhat-developer/rsp-server-community

I'm not sure if my issue was the same, but I'll post it here for posterity...

With my tomcat instance, I had an issue with the server dropping when I entered a debugger (before the server finished starting). I believe it was due to the way tomcat works.

I fixed it by placing this in the base.xml of my CATALINA_BASE (conf/localhost/base.xml):

<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Connector port="8080" connectionTimeout="-1" />
</Context>

Btw, examples like above are part of why I think publishing some basic configuration could be helpful redhat-developer/rsp-server-community#160

@pbodnar
Copy link

pbodnar commented Mar 21, 2024

A long starting server being stopped without any warning brought me here...

It looks like both server.timeout.startup and server.timeout.shutdown that were added by #596 and solve this issue, were not documented. Shouldn't those 2 be listed on https://github.com/redhat-developer/vscode-rsp-ui#extension-settings?

Also, probably for another feature request, I can't see why there is currently no notification about forcefully stopping the server because of the timeout. Or is it there, just not functioning?

@robstryker
Copy link
Collaborator

redhat-developer/vscode-rsp-ui#297 documents the falgs.

@robstryker
Copy link
Collaborator

robstryker commented Apr 1, 2024

Opened #723 to track the request of a notification upon timeout

@pbodnar
Copy link

pbodnar commented Apr 2, 2024

@robstryker, thank you, the changes look promising. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants