I don't have command line access (AFAIK). I'm using the IIS7.5 client (remotely)
I've tried resetting the Application Pool but the changes still don't show up (I have a Rewrite from http> httpS that may have a bug. So I deleted it from web.config and uploaded to root.)
So, either IIS7 takes a while to see it's changed, or the Rewrite is somewhere else, but where?
Related
We are attempting to deploy new PHP code via Capistrano while running Opcache.
Capistrano creates a new deploy directory each time you deploy, then adjusts a symlink so that the webserver points to the new directory. Because Opcache caches by the real path of the file, that means that the newly deployed version of a site is cached completely separately from the old.
The problem we are running into is that Opcache runs out memory because each new deploy causes the full code base to be cached, and old code is never evicted. We could call opcache_reset(), but when the cache is reset, we briefly get 500 errors when the caches stampede. (We would also have the same errors if we tried to launch a new deploy without warming up the cache.)
Is there a better way to handle this? Some way to launch the new code while not filling up opcache until it runs out of memory (or empties itself because it has too many files) that allows us to avoid calling opcache_reset() on the live site? We are using (or trying to transition to, anyway) Nginx as our web server with PHP-FPM handling the PHP requests.
An option would be to call opcache_invalidate for each of the files in the old version of the site at the end of the deployment. You could prevent cache stampede by including the file following the invalidation.
A second option would be to setup fpm to have multiple pools, and to restart them one by one (they'll start with a clean opcache). You'll somewhat prevent the cache stampede only one server will have a clean cache at any given time, and the application will stay up because nginx will be able to balance the load on the various pool.
Another option is to delete the old versions of the script, so that opcache clears them from the cache once the revalidate_freq has passed, forcing it to load the new files from the filesystem.
I have deployed my application on WAS 8 as debug. The server status is [Debugging, Synchronized]. When I put breakpoints and start the application, it doesn't stop at the breakpoints. I don't see the debugger thread start either.
I am using RAD 8.0.4 and JDK 1.6.0_31. I have tried cleaning the project and re-deploying but it still doesn't work.
I was able to get it working via a complete clean install of my app. Then removing it from the server via add remove. Clearing cache from the websphere/profiles/myprofile directory. and clearing all bits of my app from the profiles folder via a search for its containing file aka (myproject-folder). Then re-installed the app via add remove on the server and it worked for me.
Best guess I have is something was actually out of sync even though the server though everything was A okay.
WebSphere is a PITA and seems to get out of state too easily.
I'd restart the server and perhaps do a clean on the server (right click on the server, click "Clean...". If that doesn't work, you'll have to take a careful look at the location of your break points. They might not be on code that's getting executed. Place a break point further upstream if necessary, follow it down just to confirm the flow.
I am running into an issue deploying a website. Shadow copy is turned off after previous deployment issues with it and deploying the site.
Specifically at deploy time I find that even after copying app_offline.htm and verifying that the site/application is offline, the files in bin/*.dll are often locked.
With shadow copy off I would still expect the locks on the dll's to be free'd when the appdomain is unloaded on app_offline.htm appearance.
I have tried deploying a temporary web.config found on Stack Overflow which aims to prevent changes (to bin/) being picked up immediately just before I try to delete the contents of bin/
I even pause for 10s after copying the new web.config.
?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<httpRuntime waitChangeNotification="300"
maxWaitChangeNotification="300"/>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
I have confirmed with the handles util that my application pool (w3wp.exe process) is the holder of a lock on the dlls so am assuming this is the reason why I cannot delete/overwrite the files. If i manually recycle the app pool it frees it up and I am able to deploy just fine. Unfortunately as part of the deploy process copying the app_offline and changing the web.config are possible but performing IIS appcmd recycles are not (for permissions/group policy reasons) so I really need to be able to free up this lock with just app_offline.htm and the web.config.
Turning shadow copy back on does 'solve' this particular issue but if a lock is still held on the dll. However I wonder / and concerned if I am just postponing the problem. Unless the lock on the old dll is free'd when the appdomain is loaded again?
When copying the app_offline.htm the w3wp process id doesn't change like it does with a hard recycle but I assume it is unloading the appdomain which should free the bin/ files it has locked.
Another interesting point is that this only appears to happen on our production servers, I cannot recreate it locally or on our dev/staging sites. I don't believe there is any config difference with the app_pools or IIS config but could this possible cause this behavior.
Also to clarify shadowCopyBinAssemblies has been set to false for over 3 years without this problem happening (same deploy process) so I really feel like something that happened recently caused this, but I have no idea what.
Thanks for any ideas on how to solve this or even what might be causing it.
(I believe the server is IIS7 or 7.5)
I am running into a similar issue where a DLL is locked by IIS even with the presence of app_offline.htm.
Restarting the pool solves the issue but it is manual. Looking for an automated way. In my case the DLL is PDFium.dll it is likely an unmanaged dll
I have a MVC3 Web Application project that I develop and publish from Visual Studio 2012. This was recently a VS2010 project that was migrated.
My web.config is setup using a <location inheritInChildApplications="false"> tag so that a child application running in a virtual directory does not take on the settings.
I have setup a WebDeploy publish profile, which worked flawlessly in VS2010, but breaks my application when published from VS2012. It adds a <connectionStrings> node after the closing aforementioned </location> tag, even though I already have a <connectionStrings> node inside my <location> node. This breaks the app due to an invalid configuration file.
I've tried re-creating the profile from scratch which didn't solve the problem.
Based on what I have read here, http://msdn.microsoft.com/en-us/library/dd465337.aspx, unchecking the "Use this connection string at runtime" checkbox should instruct the publish process to NOT add the connection string, but it does anyway.
I'm thinking that this would not be an issue if I wasn't using the <location inheritInChildApplications="false">, because the connection string would get added to the right spot.
Also, note that if I publish to the File System instead of using WebDeploy, the published Web.Config is created correctly and does NOT have the extra connection string node added.
Are there any known workarounds for this issue?
As I suspected, this issue is related to the inheritInChildApplications attribute. It is likely a bug in the Visual Studio 2012 Web Deploy whereby the deploy process always adds the connection string to the configuration file, even if you tell it not to. In my case, it was also adding in the wrong spot, which broke my application.
To fix the issue, I simply stopped using the attribute and turned off configuration inheritance using one of the options listed here.
I can now publish without errors, but the process still adds the connection string to the deployed configuration file. Annoying but not a show stopper.
Can someone please confirm or deny my assumption below and/or offer any alternatives?
My Goal
I'd like to be able to precompile and merge my ASP.NET MVC 4 application (as documented here and here) when one-click publishing to our production environment.
The Symptom
I've got an ASP.NET MVC 4 project in Visual Studio 2012. My Web.config contains various entries that are removed in the Web.Release.config transformation. One of the removed entries is the entire configSections element because we maintain those entries in the production server's Machine.config.
However, when I configure my project to precompile and merge for release publication, I get the following error:
Unrecognized configuration section [our custom section name]
My Assumption
What I assume is happening is that it is precompiling everything locally before publishing to the production server (which makes perfect sense) but that part of that precompilation process is to resolve and validate the entire .config chain, from the project's Web.config up to my local Machine.config (which doesn't make much sense, practically). And since my local Machine.config does not declare configSections (or any of the other settings we rely on the production server's Machine.config for), the resolved Web.config doesn't validate.
And since the Web.config doesn't validate, the site can't be precompiled and so nothing is ever published to production.
The Rub
If that is indeed what's happening, then we won't be able to precompile, because the only solution I can think of (other than some potential configuration option I haven't been able to find) would be for all of our developers to have local copies of our production server's Machine.config on their machines. And that simply isn't reasonable because it defeats the whole purpose of having those common settings declared in a single location.