Thread was being aborted.
I am seeing the following error messages:
Nov 24 14:36:43 E
Thread was being aborted. SELECT COUNT(*) FROM workitem_only_view with (nolock) WHERE (workitem_updatelock <> N'd' and workitem_is_last='1') AND workitem_assigned_to_worker_id = 12 and NOT workitem_status_lookup_id in (400, 600) and workitem_modified_on <= getdate()
Nov 24 14:31:27 E
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. SELECT COUNT(*) FROM workitem_only_view with (nolock) WHERE (workitem_updatelock <> N'd' and workitem_is_last='1') AND NOT workitem_status_lookup_id in (400, 600) and workitem_assigned_to_worker_id = 47 and workitem_modified_on <= getdate()
I do not see anything right off the bat in the KB. When this is going on the NS itself does not have any issues. The DB is hosted on a seperate server with full GB connection between the two. The DB admins say that there is nothing wrong on their end.
Has anyone else seen this issue? If not I will call up support and work with them.
Hello,
I saw this KB which seems to be a bug from Symantec where a reboot was the solution...
KB30564
Also what is the commandtimeout on the database settings? 1200? 600?
Thanks
I saw that article. I am running NS 6 SP3+R8 and Heldesk 6 SP5 so I figured that article would not apply as it was affecting older versions.
Also, my NS is set to automatically reboot weekly.
I have not rebooted it yet as the problem disappeared. The problem appeared from 2:29PM until 2:36PM where several Workers (including myself) could not access the worker console. After a minute or so it would prompt for credentials even though we are using Windows authentication and then it would say that we did not have permissions to view.
I looked at the Log Viewer and saw the SQL commands timing out.
Network admins did not see anything unusual on the network at the time my issue appeared and the DBA's say there is no errors on their side during the same time frame.
Hello,
What is the commandtimeout on the database settings? 1200? 600?
One thing to look at is which processes were running at that time as there are some known conflicts especially with w3wp.exe...
Also there are some high CPU usage which have been seen time to time... due to updates/upgrades of workstations...
just 2cts...
Thanks
Command Timeout is 600.
Please could you try to change it to 900 or 1200 and try the report again, just to confirm it is or it is not this setting which impacted the aborted thread...
Thanks
I can try it but the issue is gone.
It happened for a brief period of 7 minutes.
I can keep it in mind so that if the issue pops up again I can change it.
What would happen if I change the value even though there are no issues?
Wait the next time the issue comes so you will have in mind the cycle!!! it comes and you could check if it comes a third time
Would you like to reply?
Login or Register to post your comment.