This is a reference document which helps you understand and debug problems with wstemp workspace directories that contain workspace directories named 'anonymousxxxx' and ' Scriptxxxx'.
Resolving The Problem
The <WAS_ROOT>/wstemp directory is used as a temporary location for configuration files when a user logs into the IBM® WebSphere® Application Server administrative console or when using wsadmin command line utility.
When the user log into the console (or wsadmin), a directory is created under the wstemp directory that represents the user ID used to log in. Within this directory, a workspace folder is created to store temporary configuration data. WebSphere Application Server is responsible to clean up the workspace directories when the customer is logging out from the console using the logout option, otherwise it remains forever.
Customers can use the ConfigService MBean interface which provides programmatic capability to query or modify configuration data locally or remotely and manage the location as well as the content of configuration documents on behalf of the user.
Config service components support session concept. Users may start a session, perform a series of operations, and then save all changes made during the session into a configuration repository at one time. If any of the configuration operations failed in the middle, the user can throw away all the changes made by calling the discard method. When the user is done with the session, they must call the discard method explicitly to recycle the resources used by the session. The following example code shows how to the session is typically used:
Session session = new Session();
If the session is null, then the operation will be executed in a separate anonymous session. For example, the operation creates a new session, does the work, and saves the session in one method call. However, session creation is not cheap, so it is recommended that the user creates a session and reuses the session whenever it is possible.
If workspace directories named "anonymousxxxx" are created in the /WAS_HOME/wstemp directory, then this indicates that application code was created during these sessions using the configService API. When the user is done with the session, they must call the discard method explicitly to recycle the resources used by the session. If these anonymous workspaces can be seen, then they continue growing and/or remain forever, and it is likely that the user did not call the discard method to clean it up.
The following snippet from trace.log file with trace string "Admin=all:management=all:Workspace=all" may help you understand how a log file looks like when a workspace is created:
In the trace, search for "WorkspaceHelp > getWorkspace Entry". It should resemble the following:
[8/5/05 15:28:38:285 EDT] 0000003a WorkspaceHelp > getWorkspace Entry Script10588143000
This shows a workspace is created for a wsadmin call. If client application is making these workspaces, it would be anonymousXXXXX instead of Script10588143000
Then you can check what the workspace is used for, for example, you might see: [8/5/05 15:28:38:285 EDT] 0000003a ConfigService > queryConfigObjects
Entry Script10588143000 <null> WebSphere:_Websphere_Config_Data_Type=Server <null>
This shows a queryConfigObjects() is called, using workspace Script10588143000
Per ConfigService API javadoc, When a user is done with the session, the user must call the discard method explicitly to recycle the resources used by the session."
Note: If user is experiencing high CPU / OOM / crash due to filling up of wstemp folder , user can always stop the deployment manager in ND set up or server1 in base set up and delete the content of wstemp folder which is safe and will not cause any issues to the runtime .
Was this topic helpful?
15 June 2018