Replies: 7 comments 15 replies
-
You can use |
Beta Was this translation helpful? Give feedback.
-
There is a very old related ticket I wonder what part of the play code exactly is triggering the application load after the first request |
Beta Was this translation helpful? Give feedback.
-
In dev mode, the code that triggers an application reload / (re-)compile can be found here: So what happens is that in a server backend this applicationProvider.get is called, which in DEV mode checks if a file was modified and eventually a re-compile happens: As you can see this happens inside the handleRequest method.So to load/compile the app eagerly, this get method(or the reload method?) has to be called once. I am not sure if it is as easy as that, but it would be worth a try. Also, I would prefer if that would be not the default, but only when running Play with a flag (or sbt setting).
Feel free to give it a shot and provide a pull request 😉 |
Beta Was this translation helpful? Give feedback.
-
I did not look into changing anything on the Play side, I simply
created a "run-app" script that calls another script (in the
background) that repeatedly calls our health API endpoint until that
succeeds, followed by "sbt run".
So effectively this:
#!/usr/bin/bash
check-health &
sbt run
(Obviously, "check-health" sleeps between calls and there is a maximum
number of calls).
This makes it act like "sbt run" (it auto reloads and you can just hit
a key to stop the app, et cetera) but because of the repeated calls to
the health endpoint, it immediately forces the complete load of the
app. I still don't understand why this is not the default behaviour
but this workaround works well enough for me.
…On Sat, Jun 29, 2024 at 9:20 AM Alex ***@***.***> wrote:
I'm running into the same problem (on startup Play just waits for a web hit).
Really don't want to have to hit service with a web browser since it's just backend services. Super annoying behavior when you develop.
Has this been improved? Is there an easy switch now?
I tried searching and AIing and nothing worked.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I am not sure I'm following you here. Surely, you're not compiling on
a PRD instance?
For PRD, you run `sbt dist` (on your build server) and you package up
the result (RPM, tarball, zip, or whatever you like). _That_ is what
you deploy to PRD. You should not have SBT, Git, your source code, et
cetera on your PRD instance.
Or am I completely misunderstanding you? :-)
…On Tue, Jul 2, 2024 at 9:06 AM Alex ***@***.***> wrote:
Oh, yeah, that's what codejoy thought of too. But this is very hacky and while ok for a dev box to have a terminal open with a ping every few seconds - this is a horrid way to deploy in production. I'm looking for a production deploy option.
Now even the compile doesn't happen till you ping the instance. So whole thing is in a schrodinger's cat stage till someone uses it. Not very adult.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I see, that is deeply unfortunate. This is where "it depends on your situation" comes in, obviously. Have you compared the results of running Regarding your "P.S.", sure, I agree that the choice of dev-JDK vs non-dev-JDK is fairly minor in the grand scheme of things. That's why we take numerous steps to secure our instances. Install as few packages as possible and create as many hurdles as possible for anyone trying to do something nefarious. |
Beta Was this translation helpful? Give feedback.
-
I really like being able to see the console output and being able to kill the app by just hitting enter but it's super annoying to have to make a request just so that the application actually starts.
Beta Was this translation helpful? Give feedback.
All reactions