Websphere temp files to clean up

It is better to always remove temp and wstemp when there is any update with application or re-deploy the application . But safer to take backup of the complete profile before making any deletion .

profile_root//temp and profile_root//wstemp these are the location of the temporary files in Websphere Application server .

WebSphere Application Server uses multiple temporary locations for many reasons. This post explains the most commonly used temporary files, why they are used and when they can be removed. This blog will also explain the files and directories that can be removed under the profile direction with caution.

Important:

  • Be careful in deleting any temporary, cache and log files in WebSphere Application Server!
     
  • Before making any changes to the environment , take a backup of the profile. It can be a tape backup, using the backupconfig tool, or using the manageprofile -backupProfile option.

    profile_root example: C:/WebSphere/AppServer/profiles/profile_name
    install_root example: C:/WebSphere/Appserver

Let’s describe the different files and their locations:

  • profile_root/wstemp
    Usage: wstemp is a workspace temporary directory. Any changes that you make to the configuration are stored in the wstemp directory temporarily. For example, if you are changing the heap size for an application server, the change is stored in the wstemp location until you save the changes. The concept is same for any administrative client, such as the Integrated solution console, wsadmin or JMX, that you use to make the changes.

    Caution: The WebSphere Application Server administrative console stores a preferences.xml file in install_root/wstemp/<workspace_id>. This file contains user preferences on administrative console layout and actions. It is created when you log onto the administrative console. If you remove this file, you lose the user preferences; however,  the preferences can be created again the next time you log onto the administrative console.

    Do not delete the wstemp files when the server is running (especially deployment manager or node agent servers). This approach can cause unexpected results. Also, do not delete the files when you are unsure about the changes that you made to the configuration. Save any pending changes, stop the deployment manager or node agent, which depends on whether you are removing the dmgr wstemp or node wstemp, and then delete the wstemp files.

    Why remove these files?: Files in the profile_root/wstemp directory can be removed. Restart the server process after removal. Because the directory is  used by multiple clients, some times you might see multiple files and subdirectories left behind in this directory. For example, when you use the ConfigService MBean to make changes to configuration and you do not discard the session in the code, this directory will never get deleted. Another reason is corruption in the workspace. Corruption can happen when multiple users make changes to the same configuration at the same time.
     
  • profile_root/temp
    Usage: The temp directory is used by multiple WebSphere components. Two good examples are compiled Java ServerPages (JSP) files and web service cache files. Compiled JSP class files (servlets) are stored in this location. The directory might get regenerated when you invoke the JSP again. However, you might experience a performance issue when you invoke the JSP for the very first time after the JSP compiled files have been removed.

    Caution:  Be cautious if you have a web services application deployed on the node. The wscache.xml is generated during the deployment process and stored under the temp directory. You have to redeploy the web service application to generate the wscache.xml again. You may experience some performance issue with large and complicate webservices application

    Why remove these files?: Corrupted JSP files or any non-root permission issues might cause the server start up issue.

Never delete any other files or directories for WebSphere Application Server unless otherwise directed by the IBM Support team.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *