I'm using the supervisord state to manage my web app instances.
When a config file changes, I want to reload the supervisor config and restart affected instances. I currently do this using the watch prerequisite in a supervisord.running state, but the default supervisord.mod_watch state function only restarts my instances without reloading the config.
The docs say supervisord.mod_watch has a reload option, which is False by default. If I could somehow set it to True my problem would be solved. Does anyone know how to do this?
Btw: I already tried to use the onchanges prerequisite and just set reload: True when using supervisord.running, but somehow that prereq never gets triggered.
Related
I'm using FastAPI and the Uvicorn server to build a website, but when I make changes to the CSS files and reload the webpage it doesn't pick up these changes.
In fact, even when I switch off the server and reload it, Uvicorn still doesn't pick up the changes to the CSS file.
Previously, the server picked up the changes fine, what's caused this to change?
The issue is not with Uvicorn, but with your web browser stashing 'static' files in its cache.
FastAPI uses a method that designates a directory the 'static folder'. This tells the server that the files in this directory should remain constant and don't need to be downloaded every time a webpage is loaded.
Check inside your app's main module and look for the following piece of code:
app.mount(
"/your_static_file_web_path",
StaticFiles(directory="your_static_directory"),
name="your_name_for_static_app"
)
This function creates a second FastAPI app within your pre-existing one that handles all of your static files. The second argument defines your static file directory. Anything within that directory will eventually be cached by your web browser and further changes will not be loaded. This prevents your page from loading the updated CSS.
As noted in a comment above, if you want to work around this issue, you can hold shift and reload the web page - this is known as a hard refresh. A hard refresh will force your browser to re-download everything, including static files.
I use QML Settings in my application. Therefore, while developing and testing, every time I open the app, it remembers the settings.
How can I clear the settings status so that I can simulate the very first launch of the app by a user? Thanks.
You can specify the file that is used to store the Settings by setting the filename property.
Settings {
filename: "/path/to/my/settings/file"
}
Then when you want to clear the Settings, simply delete the file. Everything should start over with default values after that.
I am following headfirst JSP and Servlets book these days and it says that ServletConfig object is only created once during the life cycle of a servlet before being passed down to the init method of the servlet.
I was testing out some examples given in the book to just print out the init-params and context-params defined in the DD of my webapp using the out.println method of HttpServletResponse.
What I am seeing this is if I make any change in the DD (adding or changing param names, values) and reload the URL in my chrome browser pointing to that particular servlet inside the webapp it gets updated with the newly added params. This should not be the case. I am not redeploying the servlet (by stopping and re-running the tomcat service again) which will cause the ServletConfig object to be recreated. What is happening here?
I am running this on tomcat9 over windows 8 while the book refers to tomcat5. Has there been changes since to dynamically update the ServletConfig and Context init params? I couldn't see anything indicating this on the internet.
Look at the Tomcat logs and you 'll see the app being re-deployed.
By default changes to web.xml will trigger an application redeployment. The check for modifications happens every 10-15 seconds (I forget exactly how often).
This is the default behavior where tomcat automatically re-deploys the application
when /WEB-INF/web.xml file is updated.
As per the documentation at
http://tomcat.apache.org/tomcat-9.0-doc/deployer-howto.html#Deploying_on_a_running_Tomcat_server :
"If the Host autoDeploy attribute is "true", the Host will attempt to deploy and update web applications dynamically, as needed, for example if a new .WAR is dropped into the appBase. For this to work, the Host needs to have background processing enabled which is the default configuration.
autoDeploy set to "true" and a running Tomcat allows for:
Re-loading of a web application if the /WEB-INF/web.xml file (or any other resource defined as a WatchedResource) is updated."
To bypass the default behavior set autoDeploy to false and restart the tomcat.
You can update the server.xml to set autoDeploy to false value.The file located at
$CATALINA_BASE/conf. Tag name is Host as given below
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
I can only update the "server.xml" file, although the documentation says : In earlier versions of Tomcat the content of a Context Descriptor configuration was often stored within Tomcat's primary configuration file server.xml but this is now discouraged (although it currently still works).
So in answer to your query , no there has been no change with respect to setting autoDeploy to true or false as per the documentations of tomcat 5.x.x and tomcat 9.x.x. I am also running tomcat 9.x.x as I verify this default behavior by setting autoDeploy to false .
I thought I knew ASP.NET well, until a couple of hours ago. I am aware an IIS can recycle an app domain due to a variety of reasons including changes to web.config/bin/App_GlobalResources etc. file/directories, or otherwise on schedule or on specific events (like reaching a specific memory threshhold).
I was very sure my code was NOT hitting any of these conditions. Basically a regular http request would trigger a small task in a background thread (ThreadPool.QueueUserWorkItem) that woould lead to writing of a pdf file inside a sub-directory of my ASP.NET app.
This sub-directory had nothing that would qualify it for causing a app recycle. It was something like:
My Site\CompanyName\Mailer\UploadFiles
Please don't suggest reasons like configuration or bin directory change, the code is changing nothing in ASP.NET folders. Its writing to a pdf file inside a non-ASP.NET directory.
I used the Application_End event to figure out the reason of recycle (using reflection as suggested here: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx) and got this:
_shutDownMessage=Directory rename change notification for 'd:\Projects\MyProject\trunk\dev'.
dev dir change or directory rename
HostingEnvironment initiated shutdown
HostingEnvironment caused shutdown
Directory rename change notification for 'd:\Projects\MyProject\trunk\dev'.
dev dir change or directory rename
I am practically stumped. I am very sure I have written code on other projects which writes under the app's sub-direcories without causing app recycles. But not in this case.
Am I missing something? Is it expected for IIS to recycle the app domain trying to write to any sub-directory of the app from the ASP.NET app itself?
There is a thingy called FileChangesMonitor which has a list of folders to watch and will trigger an app recycle if any of these change. It seems that as soon as a resource (an html page, an image, or, in your case, a pdf) is served through an HTTP request, the folder where it is located becomes an ASP.NET folder, i.e. is added to the list and monitored for changes. And it does not matter whether the resources are located inside or outside the application root. I experienced this problem with folder deletes, but I guess the same thing would occur with renames. This is frustrating, because it makes serving volatile static resources very difficult.
We have our sites under a main folder we'll call call "d:\sites". "d:\sites" is shared as \server1\sites with read only access for our Dev and QA groups. I added another read only group to the share permissions (not NTFS) and the site started to recompile. I wasn't sure what I had just seen, so I did it on another server and the same behavior occurred.
We use dynamic recompilation, and I can't find a reference that says this should cause a recompile to occur (ref.[1]: http://msdn.microsoft.com/en-us/library/ms366723%28v=VS.100%29.aspx)
Has anyone else seen this, or know why it is happening?
If permissions are inherited from the parent, then adding this new permission changes the file. This change in the state of the file is picked up by IIS as a change, so the dynamic recompile is triggered. IIS treats even permission changes as if it was a change to the code base.