Microsoft Office Project Server 2007 Queuing System

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • Overview

  • Queuing process

  • Queuing architecture

  • The Project and Timesheet queues

  • Queue deployment

  • Queue groupings

  • Queuing states

  • Queue management

  • Administering the queue

This article describes the Microsoft Office Project Server 2007 Queuing System, which is a new, key feature in this version of Project Server. The article provides an overview of the Queuing System, the queuing process and architecture, the methods in which queuing jobs are grouped, states that queuing jobs can be in, and how to manage queuing through the Microsoft Office Project Web Access user interface.

Overview

A queue is a waiting line that becomes a necessity when the number of service requests becomes greater than the optimum serving capacity. In an Enterprise Project Management System, there are several instances when this is true. For example:

  • At the end of the workday on Friday, nearly all 500 employees of a small company submit their timesheets.

  • A few hours before their team status meeting, nearly all project managers publish their projects.

The purpose of the Office Project Server 2007 Queuing System is to handle these abrupt changes in demand gracefully and reliably. The Office Project Server 2007 Queuing System takes all the users' input, records entries for the requests in Microsoft SQL Server, and then processes the data asynchronously on a first-come, first-served basis. Having a queue ensures that the Office Project Server 2007 EPM solution does not stop working when a spike in demand occurs.

Nearly all critical operations in the Office Project Server 2007 system go through the Office Project Server 2007 Queuing System. These include:

  • Project Save

  • Project Publish

  • Timesheet Save

  • Timesheet Submit

  • Project Backup/Recovery

  • Report Data Service operations

  • Cube Building Service operations

  • Server Side Scheduling (and node-consistency processing)

The Project Server Queuing System provides the following advantages:

  • Reliability

    1. Data integrity: There is a well-defined protocol to save any job in the queue. If a job is just half-saved, it is not processed. Also, all jobs are saved into SQL Server (not the file system) and take advantage of SQL Server transactions.

    2. In-order delivery: If a user of Project Professional clicks Save and then Publish, the Project Queuing System ensures that the Save job is processed first and is then followed by a Publish job.

    3. Fault tolerance: Failed jobs in the queue can be retried. Also, when more than one instance of the Queue NT Service is running, if one of them stops responding, the other one picks up the extra load automatically. (This process is called transparent failover.)

  • Scalability

    1. Multithreading: The Office Project Server 2007 Queuing System can process multiple jobs at the same time. For example, Project 1 Save, Project 2 Publish, and a cube building job can be processed simultaneously.

    2. You can simply add more middle-tier servers to handle load better. Each middle-tier server will have a Project Queuing Service, and the loads will be balanced automatically.

    3. The number of jobs in the queue is limited only by the scale limitations of SQL Server.

  • Manageability

Queuing process

The following illustration shows the queuing process:

Project Server 2007 queuing process

  1. The user makes a server request from a client application (for example, publishing a project from Project Professional). The user passes a Job ID (a unique identifier that tracks the request) as part of the request.

  2. The Project Web service takes the request and puts it in the queue.

  3. A Job ID is issued to the user as an acknowledgement.

  4. The user queries to check the status of the request through the issued Job ID.

  5. The Office Project Server 2007 Queuing System returns the status of the request to the user.

Queuing architecture

The Project Server Queuing System logical architecture is composed of the following four modules.

  • Job Storage

  • Job Polling

  • Job Processing

  • Job Status Check and Management

When requests are made of the Project Server Queuing Service, such as adding or processing jobs or retrieving status, these modules work as a whole to fulfill the required task. This section describes this process in detail.

Queuing modules

The Queue NT Service is installed on every Project Server application server computer as part of provisioning. It starts one "Queue Worker Process" per Shared Services Provider (SSP) defined in the farm. The Queue Worker Process services all the instances of Project Web Access (PWA) that are associated with its SSP, and it runs under the "SSP Administrator" identity. Remember this deployment model when going through the rest of this section. For more information, see Queue deployment later in this article.

Project Server 2007 queuing NT service

The Project Server Queuing System is composed of the following four modules:

  1. Job Storage: Queue jobs are stored in the Draft and Published Project Server databases. In this manner, the jobs are backed up and restored as part of the normal Project Server database backup and recovery routines.

    Job storage

  2. Job Polling: Job storage is polled at regular intervals by a Job Polling thread to check for new jobs. Polling intervals are configured by administrators in the Project Web Access Queue Management pages.

    Job polling

    1. The Queue Worker process starts the Job Polling threads for each instance of PWA that it services. The Job Polling thread runs inside the "Queue Worker Process" process and under the "Queue Worker Process" identity.

    2. The Job Polling thread has two main properties:

      Property Description

      Type

      A given job polling thread could be a "project job polling thread" (looking for project-related jobs) or a "timesheet job polling thread" (looking for timesheet-related jobs).

      Project Web Access instance

      Every job polling thread looks for jobs originating from a specific instance of Project Web Access.

  3. Job Processing: The Job Polling thread spawns one Job Processing thread for each job that it finds. The maximum number of Job Processing threads can be configured by administrators. Note that the job processing threads reside within the "Queuing NT Service" process and run under the "Queuing NT service" identity.

    Project Server 2007 - queue job processing

  4. Job Status Check and Management: This is the module of the Project Server Queue that the end user sees.

    Job status check and management

    1. Project Web Access Manage Queue page: Administrators use this to see the status of any job in the queue. They can also cancel or retry failed jobs. This feature is part of PWA — there is no need to download a special tool.

    2. Project Web Access Queue Settings page: Administrators can view or change the settings of a queue, such as the polling interval and the maximum number of job processing threads. This feature is part of PWA — there is no need to download a special tool.

    3. Project Web Access My Queued Jobs page: Any user can check the status of a job using this interface. This feature is part of PWA — there is no need to download a special tool.

    4. Queue Status PSI: Software developers can use these APIs to get the status of any queue job. There are several powerful filters to narrow the search.

How it all works together

The Project Server Queuing System modules must interact and work as a whole when the system is tasked with requests, such as adding jobs, processing jobs, and retrieving job status.

Adding Jobs

There are many ways in which jobs can be added to the queue. For example, a project manager can save a project from Project Professional, a team member can submit a timesheet, or a third-party application can publish a project. Each of these actions causes a call to an element in the Project Server Interface (PSI), which in turn adds the appropriate jobs to the queue.

Adding jobs--architecture

Job Processing

Job processing occurs in different phases and involves interaction between various modules:

  1. Start Queue Worker Process: When the Queue NT Service starts, it starts one Queue Worker Process per Shared Services Provider defined in the farm. The Queue NT Service should always be running for the Project Queuing System to work.

  2. Start Job Polling threads: When the Queue Worker Process starts, it starts the job polling threads, which are specific to instances of Project Web Access.

  3. Pick up new jobs: The polling thread looks for new jobs in the project databases.

  4. Create job processing threads: If there are new jobs, job processing threads are created.

  5. Write status: Once a job processing thread finishes, the status of the job (success or failure) is written back to the database.

    Project Server 2007 job process queuing

Retrieving status

Job status can be checked in various ways. Administrators can use the Project Web Access Queue Management pages, team members can use the My Queued Jobs page, or software developers can programmatically get status using the Queue PSI methods. For more information about PSI methods, see the Project 2007 SDK Documentation in the MSDN Library online (https://msdn2.microsoft.com/en-us/library/bb187390.aspx).

Project Server 2007 job status check

The Project and Timesheet queues

The Office Project Server 2007 Queuing System is composed of two separate queues:

  1. Project Queue Primarily used for project-related messages such as Saving, Publishing, Reporting, and Cube Building, although other types of messages may be sent to this queue as well. Its tables and stored procedures are stored in the Office Project Server 2007 Draft database.

  2. Timesheet Queue Primarily used for timesheet-related messages such as Timesheet Save and Timesheet Submit, although other types of messages may be sent to this queue as well. Its tables and stored procedures are stored in the Office Project Server 2007 Published database.

The two queues are designed the same way, except that their jobs reside in different databases. The advantages in having two types of queues include:

  • Performance: Storing queue job data in the same database as the core data saves the queue from making expensive cross-database calls during job processing. Let’s look at an example: When a Timesheet Submit job occurs, the data entered by the user (for example, hours worked) is packaged as part of the submitted queue job and put into the SQL Server job store. Also, there is already existing information about a timesheet (duration, name, and so forth), and this information is available in the "Published" database. To process the Timesheet Submit job, both sets of data are necessary. Performance is improved if both these sets of data reside in the same database. That is why Timesheet queue jobs are stored in the "Published" database (where all timesheet core data resides) and Project queue jobs are stored in the "Draft" database (where most of the project core data resides).

  • Fine-tuning: Every setting in the queue can be specified separately for the Project and Timesheet queues. This gives administrators flexibility in configuration. For example, if a customer is using Office Project Server 2007 primarily for timesheets and there are very few projects, the polling interval of the project queue can be set to one minute, and the polling interval of the timesheet queue can be set to 10 seconds.

    Note

    The polling interval specifies the frequency with which the queuing service checks either of the queues for new jobs. This setting can be specified in the Project Web Access Queue Settings page.

How the Project and Timesheet queues are used

The following image shows how the modules in the Project Server Queuing System work with the project and timesheet queues.

Project Server 2007 queuing architecture

  1. Start Job Polling threads: For every instance of Project Web Access serviced by the queue (the queue can service more than one instance of Project Web Access), a polling thread pair is launched — one thread to service the project queue, another to service the timesheet queue. Both of these threads reside within the "Queue Worker Process" process space and run under the "Queue Worker Process" identity (which is the Shared Services Provider Administrator identity).

  2. Job Storage: As mentioned above, the project-related jobs (Project Save, Publish, Reporting, CubeBuilding, and so on) are stored in the "Draft" database. The timesheet-related jobs (Timesheet save, Timesheet submit, and so on) are stored in the "Published" database.

  3. Job processing: There is no change here. As and when the "job polling threads" discover new jobs, new job processing threads are created. Note that the job processing threads still reside within the "Queue Worker Process" process space and run under the "Queue Worker Process" identity (which is the Shared Services Provider Administrator identity).

    There is no change for the status-checking modules — they just check for status of a job, they don’t care which queue the job is part of. Queue management is always done on a per-queue basis — in the Project Web Access Queue Management pages, administrators have to select which queue (project or timesheet) they are changing the settings for.

Queue deployment

To understand how the Project Server Queuing System is deployed, you need to understand how Office Project Server 2007 is deployed in general. This section provides a brief overview of the deployment process. For more information, see Deploy Project Server 2007 to a server farm environment.

Even after reading the previous sections, there may be a number of basic questions in the reader’s mind:

  1. How does the Queue NT Service get created in the first place?

  2. How does the Queue NT Service get started — for example, how does it find the location of the Project Server Draft and Published databases?

  3. What happens when provisioning more than one instance of Project Web Access (which creates more Project databases)?

  4. What happens when provisioning more than one SSP (which creates more Queue NT Services)?

This section addresses these questions.

How the Queue NT Service is deployed during Project Server 2007 installation

This section explains how the queue is deployed in context with a brief overview of Office Project Server 2007 deployment.

  1. Prepare your computers: Determine the physical architecture for your deployment. For this example, we identify two computers for running the Web application (serving Web pages), one computer for the middle-tier operations (project save, project publish, and so on) and one computer for the database.

    Prepare computers

  2. Create a Project Server farm: As soon as you try to install Project Server on any of the computers, you will be prompted to create a farm (or join an existing farm). You can roughly think of a Project Server farm as a conceptual representation of your installation — the farm infrastructure takes care of deploying the right things at the right place. Creating a farm also creates a farm SharePoint Central Admin Web site from which you can control all farm operations from a central location. A farm includes a farm Configuration database, which holds configuration information about all the servers in your farm.

    Create a farm

  3. Install binaries and join farm: The next step is to install Office Project Server 2007 on all the computers and join the Project Server farm. As part of this process, you get to designate a role for the computer on which you are executing the installation —either "front-end Web" or "Application server" (middle-tier computer).

    Install binaries and join the farm

  4. Provision a Shared Services Provider (SSP) in the farm: When provisioning an SSP in the farm, the services/components necessary for a Project Server Shared Service are installed on every computer with the role 'Application Server'. Among other things, it would create the Queue NT Service, the Events NT Service and the PSI Web application. The white callout in the diagram below shows the logical configuration of the farm. In this case, an SSP gets created in the farm.

    Provision the Shared Services Provider

    Some things to note:

    1. The farm infrastructure takes care of installing the required components on every middle-tier computer. If there is more than one middle-tier server, these servers automatically share the load.

    2. Each of these NT services runs under the identity of the Shared Services Provider application pool. It cannot be managed manually through the Services option in the Windows Server 2003 Control Panel. The SharePoint Timer service periodically synchronizes the NT Service credentials with the Farm Administrator account o n the Farm Configuration database.

    The NT Services will not do anything at this point, because they do not have a Project Web Access site to service.

  5. Provision Project Web Access: This is done by navigating to the SSP Admin Web site and creating an instance of Project Web Access. Once you have completed this step, you have created the services/components necessary for an instance of Project Web Access. The provisioning process also notifies the Queue and Events services that there is now a Project Web Access site to service. The white callout in the diagram below shows the logical configuration of the farm. In this case, a new instance of Project Web Access (for example, PWA1) gets created in the farm and is linked to the SSP created in the previous step.

    Provision Project Web Access

    Some things to note:

    1. A Windows SharePoint Services site collection and associated application pools get created on every computer that is a front-end Web server.

    2. Four Project Server databases get created.

    3. Entries in the configuration database are created that register the relationship between the PWA site, the SSP, and the databases.

  6. Provision one more instance of Project Web Access: It is a very typical customer scenario to create more than one instance of PWA in a farm (for example, to service http://project20007/sales and http://project2007/marketing). When this occurs, new sets of Project Server databases are created, as well as more PWA Windows Sharepoint Services site collections and application pools. The white callout in the diagram below shows the logical configuration of the farm. In this case, a new instance of PWA (for example, PWA2) gets created in the farm and is linked to the SSP. Note that a new set of Project Server databases are created for the PWA2 instance. Now the Queue and Events NT services start servicing all the PWA sites attached to the SSP. In this case, they start servicing both PWA1 and PWA2.

    Provisioning another Project Web Access instance

The Queue NT Service on multiple Project Server Application servers

The Queue NT Service is created on all Project Server Application servers (also referred to as "middle-tier servers") in the farm. For example, if you have two Project Server Application servers, as soon as you provision a new SSP in the Project Server farm, a new Queue NT Service is created on both of these computers. It is important to note that the Queue NT Service services all the instances of PWA attached to its parent SSP.

Queuing Service properties

As noted previously, the Queue NT Service is created when an SSP is provisioned in the Project Server farm. When you are viewing the properties for the Queue NT Service middle-tier computer, it is important to understand how some of these properties are determined.

Queuing services properties

  • Queue Service Name: The name of the service is ProjectQueueService. Irrespective of the number of SSPs in the farm, there is always just one Queue NT Service on the Project Server Application server.

  • Queue Startup Type: Startup type is automatic because the Queue NT Service should always be running.

  • Queue NT Service logon account: The Timer Service account is set as the Queue NT Service logon account (this is the account you would have used when creating the farm).

How the Queue NT Service bootstraps and starts servicing instances of Project Web Access: The Queue runs as the Timer Service account and has access to the farm Config database. On startup, the Queue NT Service queries the Config database and gets a list of all the SSPs provisioned in the farm. Then for each SSP, it starts a Queue Worker Process. Each Queue Worker Process finds the list of instances of PWA associated with the SSP, and starts a pair of polling threads for each instance of PWA.

When do we need to restart the Queue NT Service?: Ideally, never. The Queue NT Service continuously listens to changes in the Farm Configuration — and if there is a change, it automatically adapts to the change (without the need for an NT Service restart).

Processes you will see in Windows Task Manager: If you open the Windows Task Manager, you will see a number or processes with the same name: “Microsoft.Office.Project.Server.Queuing.exe”. One of them would be running under the Timer Service account — this represents the Queue NT Service itself. Then there will be as many Microsoft.Office.Project.Server.Queuing.exe processes as the number of SSPs in the farm, each running under the corresponding SSP Administrator account. These processes represent the Queue Worker Processes. So the total number of "Microsoft.Office.Project.Server.Queuing.exe" processes is equal the number of SSPs, plus one for the Timer Service account.

Queuing deployment in various topologies

This section explains how the queue is deployed in various topologies in which you can have multiple instances of PWA as well as multiple Shared Services Providers.

Queue Startup/Servicing with multiple PWAs

When the Queue starts up, it first contacts the farm configuration database and asks for all the instances of Project Web Access it is supposed to service. The Queue identifies itself using the Shared Services Provider GUID, which is a startup parameter for the Queue NT Service (see Queue Deployment section for more details)

Project Server 2007 dual web queuing

  1. Queue NT Service contacts the farm Config database and asks for information about all SSPs defined in the farm.

  2. For each SSP, the Queue NT Service starts a ’Queue Worker Process’, which runs under the corresponding SSP Admin account.

  3. For each SSP, the Queue NT Service gets a list of associated PWA sites.

  4. For each PWA site, the Queue NT Service gets connection information to the PWA databases.

  5. Queue NT Service starts Job Polling Thread pairs — one per instance of PWA.

  6. The Polling threads poll for new jobs.

Queue deployment in a single-SSP, multi-PWAs environment

Here is a representation of the Queue architecture in a single-SSP environment, with two instances of Project Web Access provisioned for the SSP.

Project Server 2007 queing system single SSP

  1. The Queue NT Service contacts the farm Config database and asks for information about all SSPs defined in the farm.

  2. For each SSP, the Queue NT Service starts a ’Queue Worker Process’, which runs under the corresponding SSP Admin account.

  3. For each SSP, the Queue NT Service gets a list of associated PWA sites.

  4. For each PWA site, the Queue NT Service gets connection information to the PWA databases.

  5. Queue NT Service starts Job Polling Thread pairs — one per instance of PWA.

  6. The Polling threads poll for new jobs.

  7. As new jobs are discovered, the job polling threads spawn new Job Processing threads.

Queue deployment in a Dual SSP environment

Here is a representation of the Queue architecture in a two-SSP environment, with a single instance of Project Web Access provisioned for each SSP.

Project Server message queuing

  1. The Queue NT Service contacts the farm config database and asks for information about all SSP defined in the farm.

  2. For each SSP, the Queue NT Service starts a ’Queue Worker Process’, which runs under the corresponding SSP Admin account.

  3. For each SSP, the Queue NT Service gets a list of associated PWA sites.

  4. For each PWA site, the Queue NT Service gets connection information to the PWA databases.

  5. Queue NT Service starts Job Polling Thread pairs — one per instance of PWA.

  6. The Polling threads poll for new jobs.

  7. As and when new jobs are discovered, the job polling threads spawn new Job Processing threads.

Queue groupings

There are three distinct levels of grouping for queued data:

  1. Jobs A job is a trackable packet of work that gets executed by Project Server (for example, project save, project publish, timesheet submit). Some jobs are not explicitly initiated by the user (for example, email notifications, Reporting data synch-up). Jobs are the level at which queuing is tracked (using a Job ID).

  2. Correlated Job Group A correlated job group is a categorization of jobs imposed by internal rules of Project Server. Jobs within a correlated job group are always processed together and in order (with some exceptions). In the example below, Project 1 is edited and saved from Project Professional and then checked in. Project 1 is then checked out by another user, who then publishes it. Publishing Project 1 triggers Reporting and a Reporting job is added to the queue as well. Project Server assembles a correlation group comprised of the four jobs related to Project 1. It then will attempt to process the jobs in sequence since the Project Server internal rules dictates that is a dependency between the jobs. The dependency that exists is that the Project 1 publish and the Reporting database update cannot occur until Project 1 is saved. Also, if any of the jobs in the correlation fail, the other jobs after it in the correlation group will be blocked. For example, if the Save Project 1 job (job ID 12) fails, the Checkin Project 1 job (job ID 13) should get blocked. If the Checkin Project 1 job is executed, this will lead to problems. Someone else may then checkout Project 1 (which may be in an inconsistent state due to the failed save) and then attempt to modify it.

  3. Sub-jobs Each job can be broken down further into smaller segments called sub-jobs. If a job is very large (such as saving a 10 MB project) it will be broken into multiple sub-jobs. Sub-jobs are not exposed to the PSI or the Project Web Access user.

    Different levels of queue grouping

Parent/Child Relationships between submitted Jobs

It is important to realize that parent/child relationships can exist for submitted jobs which require that further processing be done. For example, if a user publishes Project 1, a reporting request for Project 1 will be generated, as well as notification requests regarding Project 1. Note that Notifications Project 1 will always be generated, but since Reporting Project 1 is generated only if Publish Project 1 is successful, should the publish job fail, the Reporting Project 1 job will not be generated.

Parent-child relationship between jobs

Similarly, a child job may fail without any effect to the parent job. For example, if Notification Project 1 should fail, there will be no effect on Publish Project 1 since it will have already occurred. It is important to note that although the user may be aware that the publish of Project 1 was processed through the queue, he/she may not be aware that a child job may have failed. If you would like to verify what child jobs were spawned from a parent job that they had entered into the queue as well as their status, you can do this through the My Queued Jobs page in Project Web Access. Administrators can use the Queue Management UI and see all jobs in the queue.

Note

The My Queued Jobs page and the Queue management pages in Project Web Access is described in the Queue Management section of this article.

Queuing states

When a job is submitted to the queue it can transition through various states. The table below describes each of these states:

State Description

Getting queued

Job is put into the queue. A job ID is issued.

Waiting to be Processed

Job is in the queue and is waiting to be processed.

Processing

Job is being processed.

Success

Job has been successfully process. This is a terminating state in which the job can go no further.

Blocked

Job has been blocked by failure of another job before it in the same correlation group. Will retry or will cancel.

Failed and Not Blocking Correlation

Job has failed, but is not blocking any other jobs in its group. This is a terminating state in which the job can go no further.

Failed and Blocking Correlation

Job has failed and may be blocking one or more dependant jobs.

Skipped for optimization

Job has been skipped because a duplicate job has been found after it within the group. For example, a project manager may attempt the following in sequence when working with a project:

  1. Saves Project 1

  2. Publishes Project 1

  3. Changes a task in Project 1

  4. Publishes Project 1

  5. Changes the start date of Project 1

  6. Publishes Project 1

All three incremental saves to Project 1 will be processed. However, all three publish attempts do not need to be processed. If the last publish job is processed, it would produce the same results as if all three publish jobs were processed. For optimization, the first two publish attempts are skipped.

Cancelled

Job has been cancelled. A job can be cancelled from any state except the two terminating states (Success, Failed and Not Blocking Correlation).

Changes in queue state

As jobs are entered into the queue and processed, it is important to understand the possible changes in queue state that can occur. The following flowchart describes the possible paths through each state.

Project Server 2007 queuing system - edit states

State Next Possible State

Getting Queued

  • Waiting to be Processed

  • Cancelled

Waiting to be Processed

  • Processing

  • Cancelled

  • Blocked

  • Skipped for optimization

Processing

  • Success

  • Failed and Not Blocking Correlation

  • Failed and Blocking Correlation

  • Cancelled

Success

  • End

Blocked

  • Processing

  • Cancelled

Failed and Not Blocking Correlation

  • End

Failed and Blocking Correlation

  • Cancelled

  • Processing

Skipped for Optimization

  • Blocked (due to a failed job)

  • Cancelled

  • Success

  • Failed and Not Blocking Correlation

  • Failed and Blocking Correlation

  • Processing

Cancelled

  • End

Queue management

Most of the mission-critical operations in Office Project Server 2007 go through the queue. Therefore, understanding and managing the queue is very critical to the smooth functioning of your Microsoft Office Enterprise Project Management (EPM) Solution installation. For example, the following are relevant topics that may prompt you to manage the queue better:

  • My project takes a long time to publish.

  • The queue management page takes a long time to load and the number of jobs says 100,000.

  • My manager asks me how to verify that the purchase of a new middle-tier Office Project Server 2007 server (Application Server) has in fact improved performance.

Queue management can be performed through the following:

  • Project Web Access Queue Management pages

  • My Queued Jobs page

  • Performance counters

  • Queue cleanup

Project Web Access Queue Management pages

Queue management can be done through the Queue management pages in Office Project Web Access. This is similar to the central "show all jobs" screen for any common printer from which you can see all the print jobs in the queue and resolve issues if necessary. The Project Web Access Queue Management pages can be accessed through the Server Settings page in Project Web Access.

From the Manage Queue page you can:

  • See the status of all jobs in the queue.

  • Cancel or retry a job if it has failed.

    Note

     See the Queuing States section for more details about queue states.

    Note

     To view user interface information on queue management, see the Administering the queue section of this article.

My Queued Jobs page

The My Queued Jobs page provides a self management user interface — similar to the “Print spooler” on any individual PC — from which you can see the status of your own specific jobs that you had entered into the queue. Project Web Access users can access the My Queued Jobs page from the Project Web Access home page through the Personal Settings link in Quick Launch.

If a user would like to view information on all jobs that they had entered into the queue, they can do this by going to the My Queued Jobs page in Project Web Access. The My Queued Jobs page displays the following information on jobs the user entered into the queue:

  • Queue Entry Time

  • Queue Completed Time

  • Job name

  • Job type

  • Job state

  • Percent complete

  • Queue position

  • Queue type

  • Error

Additionally the My Queued Jobs page allows a user to filter all their queued jobs based on:

  • In progress and failed jobs

  • All jobs

  • All jobs in the last week

  • Successful jobs in the last week

Performance counters

There are many performance counters that are specific to queuing that administrators can use to benchmark your current Office Project Server 2007 system performance. These performance counters can be very helpful in determining if your current configuration meets your goals or if you need to justify additional resources, such as another server.

Some of the counters that are available pertain specifically to jobs, such as:

  • Average wait time for any job in queue

  • Average processing time for Publish jobs

  • Percent of jobs failed

  • Average wait time

Other counters pertain to the queue in general, such as:

  • Average queue depth

  • % of SQL Retries

  • SQL Calls per hour

  • Average processing time for Publish jobs

Queue Cleanup

As the Project Server system is being used, jobs will continue to enter the Queue and get processed. The Queue System retains the status and other metadata for every completed job – so that its status can be determined at a later time. These jobs may add up over time and may start affecting system performance, especially job status enquiries. To handle this, the Queue System has a built-in cleanup mechanism that periodically deletes jobs from the queue. The main effect of deletion is that the status of deleted jobs cannot be determined via the PSI or the Queue Management pages.

On the Project Web Access Queue Settings page, there are several configuration parameters to control this cleanup mechanism:

  • Cleanup Interval – Determines how often cleanup should happen. The default value is 24 hrs.

  • Cleanup Age Limit For Successful Jobs – Determines how often successful jobs should be cleaned up. The default value is 24 hrs.

  • Cleanup Age Limit for Non-Successful Jobs – Determines how often jobs in a completed, non-successful state should be cleaned up (for example, Jobs in Failed but Not Blocking Correlation). Default value is 168 hrs.

Note

More details about these parameters can be found in the Queue Settings section later in this article.

Administering the queue

Queue management and administration can be done through the Project Web Access Server Settings page. In the Queue section of the Server Settings page there are two options to administer the queue.

  1. Manage Queue   You can view jobs in the queue using this page. You can use the configuration options to filter jobs and only see the jobs you are interested in viewing. You can also retry or cancel one or more jobs through this page.

  2. Queue Settings   You can set configuration options that control the way by which jobs are pulled from the Project and Timesheet queues and processed. These settings get applied without the need to restart the Queue NT Service.

Manage Queue

This section describes the queue filtering options are available by selecting Manage Queue in the Queue section of the Project Web Access Server Settings page. The results of the selected queuing options will display on this page as well.

Filter Type

This filter determines the order in which jobs display in the Job Grid section. The available options are:

  • By Status

  • By Jobs

  • By Projects

  • By ID

Job History

This parameter enables you to select the date range of jobs that display in the Job Grid. Use the From and To fields to select a beginning and end data.

You can use the Maximum Number of Jobs field to limit the number of jobs that display for a given date range. If the selected date range contains a huge number of jobs that need to display in the Job Grid, the load time for the Manage Queue page can be very long. The Maximum Number of Jobs field allows you to limit the jobs that display. The default setting is 500.

Job Type

This section enables you to select the job types (for example, Project Publish, Timesheet Submit, or Resource Plan Checkin) you want to appear in the Job Grid. By default, all job types will be listed in the Selected Jobs list.

Job Completion States

This section enables you to select the job completion states you want to appear in the Job Grid. By default, all job completion states other than Success are in the Selected Job States list. This means that jobs that have successfully completed will not appear in the Job Grid.

Choose Columns

This section enables you to select the columns that will appear in the Jobs Grid section.

Advanced Options

This section enables you to specify special operations that apply to a cancel operation. The options enable you to:

  • Cancel Jobs Getting Enqueued

  • Cancel Subsequent Jobs in the Correlation

Job Grid

This section enables you to view the jobs that meet the criteria listed in the Manage Queue page. Options within this section enable you to select a job or group of jobs and to apply the following options to them, if applicable:

  • Retry Job

  • Cancel Job

    Note

    You must manually refresh the View/Select job list to update the page. You can do this through the Refresh button that is available in this section.

Queue Settings

This section describes the queue configuration options are available by selecting Queue Settings in the Queue section of the Project Web Access Server Settings page.

It is important to note the following when configuring queue settings:

  • Queue settings are configured per instance of Project Server.

  • Queue settings are configured separately per queue type (Project or Timesheet).

  • The Queuing NT Service does not need to restart in order for changes to take affect.

  • If more than one Queue NT Service services this instance of Project Web Access (such as in a load-balanced environment), all the queue services would refresh with the settings.

    Note

    After selecting your configuration options on this page, make sure to use the Save button on this page to save your configuration settings.

Queue Type

This section enables you to specify which queue type (Project or Timesheet) to which you want the setting to apply.

Maximum Number of Job Processor Threads

This section enables you to specify the maximum number of job processor threads that can run at the same time. The valid range is between 1 through 20, with the default value of 4.

Polling Interval

This section enables you to specify the time interval (in milliseconds) in which the Queue NT Service polls the project or timesheet database (depending what you selected for Job Type) for new jobs. The valid range is 500 through 300000, with a default value of 1000.

Retry Interval

This section allows you to set the length of time (in milliseconds) between retries for jobs that have failed through SQL-related issues, such as SQL deadlocks. The valid range is 0 (immediate retry) to 300000, with a default value of 1000.

Retry Limit

This section allows you to set the limit on retries on a failed polling query. The Project Server Queuing System polls the databases on a regular basis to retrieve jobs that need processing. If this query should fail for an SQL-related reason, the system will attempt to poll the database again after a period of time.

SQL Retry Interval

The queue polls the database at regular intervals for jobs that need processing. If the query fails, this section allows you to set the length of time (in milliseconds) before the query is retried. The valid range is 0 (immediate retry) to 60000, with a default value of 1000.

SQL Retry Limit

The queue polls the database at regular intervals for jobs that need processing. If the query fails, this section allows you to set the number of times the query will be retried. The valid range is 0 (no retries) to 100, with a default value of 5.

SQL Timeout

The queue makes SQL calls for retrieving and executing jobs. This section allows you to set the timeout value (in seconds) for these calls. If any job fails due to an SQL Timeout error, you can increase the value for this setting and retry the job. The valid range is 19 to 86400 (one day), with a default value of 30.

Cleanup Interval

This section allows you to configure the frequency (in hours) with which the Queue Cleanup job runs. The valid range is 1 to 100000, with a default value of 24 (one day).

Cleanup Interval Offset

This section allows you to the time of day at which the Queue Cleanup job will run. The value is set by entering the number of minutes after 12:00 a.m. at which the Queue Cleanup job will run. The valid range is 0 (12:00 a.m.) to 1439 (11:59 p.m.), with a default value of 0.

Cleanup Age Limit for Successful Jobs

This section allows you to set the age threshold (in hours) at which successful jobs can be purged when the Queue Cleanup job runs. The age of each job is determined by the date and time at which the job had completed. For example, if a job had succeeded at 10/1/07 10:40 p.m., and the Queue Cleanup job runs at 10/2/07 11:55 p.m., then the job will be purged (assuming the Cleanup Age Limit for Successful Jobs value is default value of 24 hours).

The valid range is 1 to 100000, with a default value of 24 (one day).

Note

Typically the number of successful jobs in comparison to non-successful jobs in very high. Therefore, Cleanup Age for Successful Jobs is usually set to a lower value in comparison to the Cleanup Age Limit for Non-Successful Jobs value.

Cleanup Age Limit for Non-Successful Jobs

This section allows you to set the age threshold (in hours) at which a job in a completed, non-successful state (for example, Failed But Not Blocking Correlation) can be purged when the Queue Cleanup job runs. The age of each job is determined by the date and time at which the job had completed. For example, if a job was cancelled at 10/1/07 10:40 p.m., and the Queue Cleanup job runs at 10/2/07 11:55 p.m., then the job will be purged (assuming the Cleanup Age Limit for Non-Successful Jobs value is default value of 24 hours).

The valid range is 1 to 100000, with a default value of 168 (seven days).

Bookkeeping Interval

There are a number of "bookkeeping" tasks that are run by the Queuing System. For example, these include awakening jobs in a "sleeping" state, updating the heartbeat timestamp, or checking if the Queue Cleanup job needs to be run. This setting controls the time interval (in milliseconds) at which these tasks are run.

The valid range is 500 to 300000, with a default value of 10000 (ten seconds).

Queue Timeout

In a farm containing multiple Application servers, if the Queue NT Service fails on one of the servers, jobs are automatically distributed the remaining Application servers on which the Queuing NT service is active. A Queue NT Service is considered to have timed out if it has not updated its heartbeat for longer than the Queue Timeout value (in minutes). The heartbeat is updated by the Queue in all the Project Web Access databases that it touches (for example, each time the Published and Draft databases are polled for jobs).

The valid range is 2 to 20, with a default value of 3.

Note

The Queue Timeout value cannot be less that four times the Bookkeeping Interval at any time. If the Queue Timeout value will automatically be changed to four times the Bookkeeping value if the rule is violated.

Fast Polling

The Fast Polling setting is enabled by default and allows the Queue to process all jobs in a Waiting to be Processed state to be processed as soon as possible. However, if this fast processing overwhelms the server and the Queue needs to slow down, this setting can be disabled.

If Fast Polling is disabled, the Queue will check if there are any free threads to process jobs. If there are, the free threads will be loaded with jobs in a Waiting to be Processed state. It will then wait for the polling interval, and repeat the process.

If Fast Polling is enabled, the Queue will not wait for the polling interval if there are pending jobs. As jobs get processed, all pending jobs will start getting processed immediately.