John,
On 2/23/22 05:49, John Barrow wrote:
Christopher,
You will just change the implementation to answer the question "have any
resources been modified, but not-too-recently?"
OK
The check must be fast, otherwise it will hang-up other processes on the
server. Don't introduce any new loops or stalls. Just return true or false
as quickly as possible. The process will be repeated during the "next"
check so you only have to decide not to reload "too early"?
Not sure that I understand this point (re 'check must be fast'). I wasn't
imagining affecting the initial trigger point at all (i.e. Tomcat has
detected a change in one of the active files) so shouldn't affect the
day-to-day performance. Once Tomcat has decided that a reload is required
*and* the user has requested for Tomcat to do the reload (i.e. Context flag
is defined to true), prior to actioning the reload, add the additional
check (simple user-specified timer delay to allow the external
application time to finish deployment, and then let Netbeans carry on.
Tomcat won't even check for any changes unless <Context reloadable="true">.
Tomcat has a background thread that does all the "backgroundy things"
that need to be done. This is one of those things. If you hold-up that
thread, than you hold-up everything. That's why you can't just stall for
10 seconds and then proceed. Instead, you say "sorry, file is too new;
don't signal to reload (yet)."
You don't want to hold-up the reload process itself, either, for a bunch
of reasons. First, it's not really appropriate because "reload now"
means "reload now" not "reload when you sort of feel like it."
Your additional suggestion that the time-stamps of the amended files should
remain consistent over that period also sounds sensible. Given that Tomcat
can't implement the event model for reasons you have already explained, I
am now thinking that the event that triggers the re-build won't contain
details of what files have been amended, simply that there has been a
change.
Yes.
Snapshotting all the files within the two folders, noting the
timestamps and then polling again after the delay seems to be repeating
what Tomcat is probably already doing to trigger the event in the first
place.
Exactly. You don't need to do any of that.
Now that I just about have a development environment I can explore and
debug, I think I should spend some time around this class and learn when /
why it's called and the calls it makes to do the reload. So far, I have had
to imagine how the code is structured and so consider a solution based on
that (possibly false hypothesis).
Well, even if the unit tests won't pass within Netbeans, I'm assuming
that the built-in text editor is working. Just go to the code Mark
initially suggested and start reading. I think it will significantly
inform this conversation.
Just to be clear from other questions, I have no intention in going
anywhere near the 'rebuild' process - that is a black box as far as I am
concerned.
Good. The only process you need to tweak is the one that decides if the
context *should* be reloaded. That's a relatively straightforwar
process, currently, and you are going to make is slightly more complicated.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
