A bug in the Streaming Server ( STS ) code was uncovered related to how the code was acquiring locks while in the process of uploading offline session data into the process queue. This locking process locks all users from being able to start the streaming of an application while potentially another users process is uploading offline session data. If the number of offline records takes more than 30 seconds to upload and process the client times out and resends the offline data report. As the previous report timed out the second try also times out and the client repeats the process. The process loads the server with reports and the DB as_rep_session_info fills up with session data.
Users are unable to authenticate
Offline reports aren't efficiently processes by the server. Rather than having the client wait for the backend to process the data upload, the backend created a thread process to process the report data behind the scenes and returns in a few milliseconds so the client does not timeout and resend the report over and over again, the client wait for the backend to process the data upload the backend created a thread process to process the report data behind the scenes and returns in a few milliseconds so the client does not timeout and resend the report over and over again.
A work around to fix the problem without applying this fix is to remove all the offline report data from each client machine that is spamming the DB. The data is stored in the HKEY_LOCAL_MACHINE\SOFTWARE\AppStream\AppMgr\Servers\1\OfflineSessionReports regkey. This removal could be accomplished by created a logon script attached to a GPO that will clear the data upon each login.
A server fix was created to resolve this issue. To get the fix contact support.
How to install this point fix (once getting the fix from support)-
1. Backup the original files.
2. Replace AWE_Legacy.jar on all servers.
3. Replace AppStreamService.exe on front end servers.
4. Modify ste.conf file on back end server.
1. Backup the original files:
Do not rename the original JAR files and leave them in place; this will cause problems as Java scans the directory and loads them regardless of file name and/or extension. You are strongly advised to move the original files to a separate directory.