One of my servers is running out of capacity, mostly due to WebLogic's stage folder. I've been looking for information and it seems to be a temporal folder, but unlike older versions, on WL11g this folder is out of the tmp folder. So I'm not sure whether or not I can safely remove it.
Stage directory is where weblogic copies all the applications that it needs to deploy on to the managed servers. Wls does not delete any file from this folder. So in the long run if you have done deployment of many versions of your application then this folder can become rather large.
So yes you can delete the contents of this folder. At the time of restart wls will copy all the necessary files to this folder (this could take some time).
yes, you can delete the stage. All the necessary applications details will be there in this directory, but any how if it is a large environment(many applications are running), just take the back up of the directory or rename it and then you can safely delete the stage.
Related
I'd like to offline profile a YARN application. My application starts 10 containers. One of those starts consuming 100% CPU shortly before it crashes. I don't know which one is going to crash. And sadly, as this application starts multiple containers, they could potentially run on the same cluster hardware nodes. If I use a standard JProfiler config, I have to specify a filename for the savepoint. On my cluster, I can't use a relative path (relative to the working directory) as the folder is removed when the application crashes/finishes, so I need to specify an absolute path on the machine which then is the same for all containers overwriting their snapshots...
Is there a way to solve this issue? I'd like to offline profile all of my containers, let them write to a savepoint and pick the snapshot of the one which crashed.
Today, I found an old jprofiler-config.xml for JProfiler 7 on GitHub indicating that there are several more options available compared to the ones I see in my jprofiler-config.xml (JProfiler 11). Are you aware if there is any XSD describing the schema and what can be configured?
The "Save snapshot" action can add a number to the snapshot name to make it unique. It will check for existing files before writing the snapshot.
Since JProfiler 11, the config file only saves modified attributes and not all possible attributes. You can make changes in the GUI and observe the changes in the config file. There is no XSD for the config file format.
For Bamboo server, in the xml-data\build-dir\ folder, there are folders with numbers for names that I believe correspond to each local agent (I have 25 agents, and 25 folders in this directory, one for each agent). I want to clear the contents of this entire working directory on a regular basis. If I delete these agent folders, will the bamboo agents simply create new ones here the next time they need to?
I know there's been discussions about how to clean up the working directory on the Atlassian forums, but this is a question more about how bamboo actually works. Do the agents depend on those folders being there, or will an agent create a folder in xml-data\build-dir\ if the previous one has been deleted?
It when you clean ob the directories from the build jobs, bamboo will create new ones when the agent start to build them.
I have an already running Worklight application. We are planning to move to another production cluster tomorrow but I want to get the old .wlapp that is already deployed on the first cluster.
How can I get it? I could find a directory on the temp file of the WebSphere application server, but it is in an exploded form. When I zipped one of them and converted it to .wlapp, while the deployment was successfull, I had a Direct Update and the application failed to start...
Is it the right path?
When you build your application in Worklight Studio, the build produces .wlapp files and stores them in the yourProject\bin folder, these files do not get deleted from the bin folder unless you've manually deleted them.
appname-envname-version.wlapp
appname-common-version.wlapp
appname-all.wlapp
Where the version value changes depending on the value you've set in yourProject\yourApp\application-descriptor.xml.
A good practice would be to backup your artifacts of different versions as well as project source code (using a source control system...), so you could always restore any version... esp. if you're talking about already being in Production....
After deployment, the .wlapp file is not stored in the filesystem, but in the database.
So as for retrieving previously deployed .wlapp files if you do not have backup (this is very bad, BTW), these are stored in your database in the APP_SYNC_DATA table in the deployable column. You can try to extract and save the APP_SYNC_DATA.deployable data relevant for you as a .wlapp file.
But this really does not guarantee that it will "work" any better than your other attempt. That .wlapp is configured to work with certain server URLs, and if this new cluster is not a replica of the previous cluster, I don't see this working either... But also, without knowing more about the errors you get, who knows to what they are related (but this is NOT for this question).
I have been working on a group of installers over a few years and am starting to run into problems with the amount of disk space that is used when the package is installed. The installer works great but installs/copies a few redundant sets of files in the process. I do admit that that some of my assumptions may not be correct, but this is based on my best understanding of the MSI processes. Let me explain ...
1.) Self-extractor file - The compressed MSI, associated bootstrapper packages and setup.exe file is downloaded by the user creating the 1st set of redundant files. Not a big deal, because this can easily be deleted after install.
2.) Extracted Files folder - After running the EXE the files are extracted to a static location from which the bootstrapper is launched. This now has created the 2nd set of uncompressed redundant files on the hard drive. These files are useful to be able to re-install of debug installs as needed, but may not be needed after install is completed. It has never been clear to me whether patched installs depend on these files or only the files stored in C:\Windows\Installer. Assuming the latter.
3.) TEMP folder - As the installer runs from the extracted location it copies files to the TEMP folder and runs the files from that location. This creates the 3rd set of redundant files. Again it is not really clear whether these files can be removed after install or if there is an automated process that MSI does to make this happen.
4.) Windows\Installer folder - If I understand correctly this is where some sort of stripped out file set is stored that manages the ability to patch. So this is the 4th set of files that may or may not be smaller than the some of the extracted sets of files. This one needs to not be deleted so patching will work.
5.) Install folders - Final install location for the software. This is now the 5th set of files that are installed to my computer and of course is the desired set of files.
I would like to better understand the process so I can improve the way that I distribute our software so that I can avoid or resolve some of the issues I am seeing with needing many different sets of files. I am very open to any best practice that might be out there that I have not observed. Thanks for your help.
I can't speak to the exact bootstrapper you are using but you might investigate using the Burn bootstrapper in WiX v3.8 to create a Bundle of Packages. I know the details of how that works and it will reduce the number of copies from what you are experiencing now.
Self-extractor file - a Bundle this can either contain all the files in the single executable or download them from the internet on an as needed basis. In the latter case, the self-extractor file could be ~250K.
Of course, this can be deleted as soon as the install is complete.
Package Cache - the Burn engine carefully downloads files to the TEMP location, verifies their integrity and moves them into the well-known Package Cache without creating any other duplicates. The Package Cache is important because the Windows Installer can get into situations where it requires the original source files. If that location is in a TEMP location that was deleted the user will have a very hard time providing the original source files. The Package Cache also improves the reliability of the installs. Finally, it is a cache so it *can * be removed (although not recommended) and the next execution of the Bundle will put the necessary packages back in the cache.
Also, this content is the original source media and can still be compressed.
Windows\Installer folder - the Windows Installer will cache the .msi file. If you do not embed the cabinet files in the .msi file (which is unnecessary when using a Bundle since the Bundle can embed all the files if desired) then the cached .msi file should be less than a couple megabytes.
Install Folders - this is your application, you probably need these files here. :)
So, in the end using the Burn engine you should end up with one copy uncompressed (the app itself), one copy compressed (the package cache), and a tiny bit of overhead for the .msi file cached.
I have an IIS web application with a structure roughly similar to:
wwww.mysite.com
file1.asp
file2.asp
\DotNet
file3.aspx
file3.aspx
We are setting up TeamCity to do auto deployments. I have an MSBuild build step that deploys to the \DotNet folder (the aspx files), and in a separate build configuration I have another MSBuild build step that deploys to the root (the asp files).
I want to allow MSDeploy to delete unnecessary files, e.g. if I remove file2.asp from VCS, I want it to delete it from the target IIS server.
However, I do NOT want it to wipe the \DotNet subfolder.
Can I get something more granular than the command line switch "SkipExtraFilesOnServer", or is this an all-or-nothing deal?
It turns out that the answer to my question was much simpler than I expected
When deploying to the root folder of an application using the MSDeployPublish target via MSBuild, by default, extra subfolders that happen to be on the filesystem of the target IIS server are deleted.
To avoid this, I simply moved the contents of my DotNet folder to a totally separate location under C:\InetPub, but retained my original virtual folder/application structure under IIS Mgr. Of course!
Now I can publish to either location as much as I please, and one won't try and delete the other because one is no longer a filesystem subfolder of the other.
If anything - this highlights how primitive our earlier folder structure was, and what a doofus I am for not realising.
I'm not exactly sure what you're looking for here. Are you trying to delete all the files from within the dotnet subfolder but keep the folder? Are you trying to have the delete operation never delete anything from the dotnet folder? The msdeploy sync operation is pretty smart. msdeploy will move all of your marked project assets, so assuming you don't delete the files in the dotnet folder, then you should be fine.
If you just want to exempt the dotnet folder from any delete actions, as if it were a not part of your project at all, but its in a subfolder the web server and you want to not touch it, then I would suggest using the skip option in msdeploy with wildcards. I've only used it for files, but it should work for folders too. It goes like so:
-skip:objectName=filePath,absolutePath=app_offline\.*
There's documentation here: http://technet.microsoft.com/en-us/library/dd569089%28WS.10%29.aspx
Search the page for
-skip:skipAction=
You could also add a skip setting with name of the folder you wish to not by synced, like in the following msdeploy call:
msdeploy
-verb:sync
-source:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Source"
-dest:contentPath="C:\Data\Personal\My Repo\MSDeploy\MultiSkip\Dest"
-skip:objectName=dirPath,absolutePath="DotNet"
[I took the example from the answer to this question.]