Trying to delete projects from the Admin console in TFS 2015. State changes to "deleting", listed as "Queued" in the Status tab, never completes.
There's currently several jobs listed as "queued" in the Status tab, some from many months back. Trying to select View Log, never gets past "Waiting for the job to start", which makes sense cause it's queued.
Not sure if/why one of the older jobs are stuck or otherwise blocking up the later ones. Can delete requests be cancelled to see if the later ones will run properly?
TFS uses SQL jobs to do all kinds of maintenance. Can you check if they are running as scheduled?
Looking further, it seems to be a Windows service:
https://www.visualstudio.com/en-us/docs/setup-admin/tfs/architecture/background-job-agent
You can give a try with deleting a team project with TFSDeleteProject command
TFSDeleteproject [/q] [/force] [/excludewss] /collection:URL TeamProjectName
Also increase the Time-Out Period.
By default, each Web service call that the TFSDeleteProject command
issues to delete a component must complete within 10 minutes.
Another thing is restarting the Team Foundation Background Job Agent service in your TFS server.
Related
Can someone of you help me, how to make the following service selected in the image get into wait mode after starting the server.
Please let me know if developer trace is required to be posted for resolving this issue.
that particular process is a BATCH process, a process that runs scheduled background tasks (maintained by transaction SM36/SM37). If the process is busy right after starting the server, that means there were scheduled tasks with status released waiting for execution, and as soon as the server was up, it started those tasks.
If you want to make sure the system doesn't immediately start released background tasks, you'll have to set the status back to scheduled (which, thanks to a bit of weird translation, means they won't be executed because they are not released).
if you want to start the server without having a chance to first change the job status in SM37, you would either have to reset the status on database level (likely not officially supported by SAP) or first start the server without any BATCH processes (which would give you a number of great big warning messages upon login) and change the job status before then restarting the server with the BATCH processes. You can set the number of processes for each type in the profile of your instance (parameter rdisp/wp_no_btc).
I'm trying to execute a process to update my database, but the problem is that I set different RecurringJobs for it at different hours.
Today when I checked hangfire status, since yesterday that I instanced hangfire, I found the job should execute yesterday and the one task for today, both executed 30 minutes ago at the same time, and this has created duplicates in the database.
Can you help me with this?
If your problem is one of concurrency, you can solve it by running hangfire single threaded. Simply configure the number of hangfire worker threads on startup:
var server = new BackgroundJobServer(new BackgroundJobServerOptions
{
WorkerCount = 1
});
This will force hangfire to process queued jobs sequentially.
Alternatively, if you have the Pro version of hangfire you can control order using batch chaining.
I don't know if a worker can be considered as a thread.
Within a hangfire worker, single threaded code will be run by exactly one thread
This doesn't look like a concurrency issue as has been suggested. It's not completely clear what you are trying to do but I'm assuming you want the job to run at 7, 12:45, and 17:30 and had issues because both the 7am and 17:30 job ran at the same time (7am).
Based on the created time it looks like you created these around 14:30. That means the 17:30 job should have ran but didn't until the next morning around 7am. My best guess is this was hosted in IIS and the site app pool was recycled.
This would cause any recurring jobs that were supposed to run to be delayed until the app pool / site was started again (which I assume was around 7am).
Check out these documents on how to ensure your site is always running: http://docs.hangfire.io/en/latest/deployment-to-production/making-aspnet-app-always-running.html
If it's not an IIS issue something must have caused the BackgroundJobServer to stop monitoring the database for jobs until ~7:00am (server shutdown, error, etc).
One of my applications has been deemed business-critical and I'm trying to figure out a way to make my scheduled agents behave correctly in cases of failover. It doesn't need to be automatic, but an admin should be able to 'transfer' the running of the agents from one server to the other.
I was thinking of one solution of setting in a profile document the 'active' server, and have the agents (there are 4, 1 Java and 3 in LotusScript) check if they are currently running on the 'active' server, and if not, stop immediately.
Then there is IBM's workaround suggestion: http://www-01.ibm.com/support/docview.wss?uid=swg21098304 of making three agents, one 'core' agent which gets called by a 'main agent' running on the main server, and a 'failover agent' running on the failover server, but only if the 'main server' is available.
But that solution seems a bit clunky to me, that's going to be lots of agents that need to be set up in a fiddly fashion.
What would you recommend?
My logic is similar to yours, but I don't use profile- documents (caching is a bad thing for such important task), but a central configuration document.
Agents are scheduled to run on every server.
First they read the "MasterAppServer" from the config- document. If it is another server then they try to open the database (or names.nsf, depending on what you want) on the MasterServer. If the database can be opened -> everything is ok, agent stops its work. If it cannot be opened, then the agent assumes, that the other server is down and changes the MasterAppServer- field in the config- document to his own server and runs.
Of course I write a log in the config- document whenever "MasterAppServer" changes.
That works quite well and does not need any admin intervention when one server is down.
I have set up a Selenium Grid with 3 different servers running nodes as windows services. I need to restart those machines regularly to avoid memory leaks and under performance. To do this I need to schedule a job to shutdown the nodes on a server and restart while tests would be pushed to the remaining servers. Then repeat the same process with scheduled jobs on the other servers.
Is there a way to shut down a selenium node once the current test finishes ? Or to get the status of a particular node so I can check each one myself in a scheduled job to make sure the node is not running a test before I shut it down ?
You could check the number of active sessions by requesting each node with the /sessions command:
http://127.0.0.1:4444/wd/hub/sessions
Response :
{"state":"success","sessionId":null,"hCode":3217742,"value":[],"class":"org.openqa.selenium.remote.Response","status":0}
#Sh3mm
Sometime back I wrote up a blog post which basically talks about how to go about building a "Self Healing Grid" which is what you essentially are after.
You can read through my blog post on that from here.
We essentially used the same approach when we working on building the SeLion Grid. The SeLion Grid packs in a few more sophistications. Read more about it here
There's another flavor of essentially the same sort of functionalities that was built by GroupOn as part of their Grid Extras. You can take a look at it here
I have a job that is supposed to run every 11 AM and 8 PM. About two weeks ago, it started to not respect the schedule. The "fix" that I found was to start the job manually and then the job would restart respecting the schedule for a while but eventually the issue reappears.
The big problem is that there are no error message what so ever. If the job fails, I am supposed to get a notification Email which I do not. In the sql server agent logs and the Job history, there are no errors. In the job history, I can see clearly that the job skipped the schedule since there are no entries. It looks like it did not even start as if the running time had not arrived.
The schedule is set to run everyday and there are no limits on how long it is supposed to run. The sql Agent is set to restart automatically if it stops unexpectedly.
Did anyone get this problem before?
Check the user which is used to run the job. Maybe the user password is expired or the user itself is no longer active.