Hi all, I will consolidate the comments from the last three emails to keep the thread from splitting too much.
> Christopher: I don't think your attachment made it to the list. Maybe you can > host it somewhere else and then post a URL to the list? Attachments tend to > be stripped. I'm actually surprised your ZIP file made it through. Firstly, I wasn’t aware that text attachments would be stripped. I certainly didn’t get any notification although I did get plenty of notifications when I used Windows Mail to reply (no Plain Text support!) The URL for the sources is below which are held in my DropBox account. Hopefully the link below will allow access. Let me know if there are any issues. https://www.dropbox.com/sh/2ewipogzr48qcxi/AAAf3Rqv6WoRO9hyMC0W7P2za?dl=0 > Christopher: Don't do anything like that; it won't work in various > environments. For example, Windows obtains exclusive file-locks for even > sometimes read-only operations. But *NIX does /not/. So you may develop > something that works on Windows but doesn't work at all anywhere else. That was my understanding. When I was working, I remember there not being a comprehensive solution to this requirement and that Unix was very 'flexible' when handling files in flux, hence my query as I was not sure if something more recent had surfaced that I wasn't aware of. I believe that the 'wait a while' approach is (a) practical and (b) minimises conflicts with the way that Tomcat is operating. It is also flexible in that, if you know that you are refreshing large files then giving (say) a minute for the upload to work before Tomcat reloads is reasonable whereas if developing small Servlets then a few microseconds is probably all that is needed so the administrator can tune to the environment. > Christopher: The patch you are currently working on should fix this aspect of > the overall problem you are trying to solve. Thanks for the vote of confidence - hopefully now that you can see / run the sample app, that confidence will remain! > Christopher: It's just relative timestamps. Dive into the code Mark suggested > and you'll find it. That surprises me. I can't wait to dive in once I can get my IDE working. Is Tomcat polling the folder every 'x' microseconds then? That may explain the caution in the Tomcat documentation in that it puts a strain on the server. You will see from the sources that I have uploaded to DropBox, that I mimicked an event model that seemed to work quite well, however I am not sure which model would be more efficient and less intrusive on Tomcat's operation. > Jason: but the JAVA NIO API watchevents point you in the right direction in > watching a file/folder in a loop for a "create" or "modify" or "delete" event > to occur and fire off. As you should now be able to see from my DropBox source files, that is the approach I took although I wasn't looking to implement that, simply mock-up what I thought that Tomcat was already doing to detect the need for a reload. > I wish they would have just monitored the file size for a configurable > "given" time. And lets say - if the file size or timestamp doesn't change > for -say - 15 seconds, then go ahead and do the deployment. That would be easy enough to add in as a fail-safe and while not perfect as it makes assumptions on external factors, we can at least be sure that if either the timestamp or file size has been amended then it is still in flux whilst not offering any guarantees if they are identical. As I get an event for each file/folder that has been amended, I could then add another loop to check stability of these two attributes (say over 10 ms intervals, or add a further parameter to be user configurable) before starting the final 'waitForQuiet' timer prior to notifying Tomcat to start the reload. It is also a read-only query and so has no side-effects as it appears that users have a need to auto-reload after refreshing a larger .war file. Thoughts? Enjoy your evening. John From: Christopher Schultz Sent: 20 February 2022 14:22 To: users@tomcat.apache.org Subject: Re: <Context … reloadable = "true"> is too quick to respond John, On 2/20/22 05:50, John Barrow wrote: > Neil, > > Thanks for your useful feedback. I am still feeling my way as you can > probably see from my earlier emails trying to setup a development > environment. > > I did actually think of this but didn't put it in scope for a couple of > reasons. > > Firstly, the Tomcat documentation for readloadable quotes > > "Set to true if you want Catalina to monitor classes in > /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically > reload the web application if a change is detected. This feature is > very useful during application development, but it requires > significant runtime overhead and is not recommended for use on > deployed production applications. That's why the default setting for > this attribute is false. You can use the Manager web application, > however, to trigger reloads of deployed applications on demand." > > Therefore, I took it to mean that this flag was geared at development, > not production which is what I assume when you would deploy a .war > file. So Tomcat would be listening to specific changes in .classes and > .jar files that had just been compiled and these are normally small in > size. But then I suppose that a single .jar file may be so sized that > Tomcat could react while the file was still being written to the disk. The patch you are currently working on should fix this aspect of the overall problem you are trying to solve. > Secondly, I sort of assumed that since the feature was already in > place and handles changes to single files that this check for > completeness has already been implemented, but then as I can't get a > development environment to run, I don't have enough skills to drill > into the sources without it being interactive to help me explore and > learn. > > However, it makes sense that your recommendation is implemented, > although I was imagining setting the delay to (say) 500ms to ensure > that whatever IDE had time to complete the copying of all the files as > that is a small price to pay for automatic refresh. Also by resetting > the timer after each event it would have to be quite a large upload > for Tomcat to start reacting. > > Like you, I am not sure how to formally check that a file has > completed its copy to the destination. The most common suggestion I > hear is to try and change its name and then change it back again and > capture the exception which will be raised if the file is locked. I > wonder whether attempting to set an attribute (e.g.toggle read-only) > would have the same effect (i.e. only allow if file wasn't locked) and > be a little more elegant. I would have to try it. Don't do anything like that; it won't work on various environments. For example, Windows obtains exclusive file-locks for even sometimes read-only operations. But *NIX does /not/. So you may develop something that works on Windows but doesn't work at all anywhere else. You basically can't check to see if a file is "done uploading"" or whatever else may be happening. What you *can* do is check to see if any file in the list-of-files-to-be it *too recent* indicating that a compile/copy/upload/whatever may still be in progress. > I assume that Windows has a way of querying a file lock but not sure > (a) whether that is exposed via a Java API and (b) whether that would > apply to Unix as well (as I have only ever used Windows for > development). > >> How does Tomcat test if a file has been updated? It's just relative timestamps. Dive into the code Mark suggested and you'll find it. > Again, I don't know this yet (lack of IDE again), but I assumed that > it would be similar to the method I implemented in the attached source > code, i.e. Create a listener for events being triggered on file > changes to either /WEB-INF/classes/ and /WEB-INF/lib, as they are both > hard-coded file paths. I don't think your attachment made it to the list. Maybe you can host it somewhere else and then post a URL to the list? Attachments tend to be stripped. I'm actually surprised your ZIP file made it through. > As an aside, I should have mentioned, for anyone interested in this > thread and in case not obvious from the source, but to see the sample > source code in action, you need to add, modify, rename or delete files > within the specified directory in a File Explorer. -chris > On Sun, 20 Feb 2022 at 00:04, Neil Aggarwal <n...@propfinancing.com> wrote: >> >> John: >> >>> If anyone has a moment, can you have a quick look and see if what I am >>> proposing seems acceptable. >> >> Thinking about when a large file (Such as a war file) is being uploaded >> to the server, we don't want Tomcat to reload it until after the file has >> completed upload and is fully formed. >> >> How does Tomcat test if a file has been updated? >> I assume it uses File.lastModified() or something similar. >> >> Does anyone know the detailed nuts and bolts of how that works? >> Does last modified keep changing as the file is uploading or is it just >> changed at the start of the upload? Is the behavior the same or different >> across platforms? >> >> These questions should be taken into account when designing the solution. >> >> Thank you, >> Neil >> >> -- >> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com >> We offer 30 year loans on single family houses! >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
