Naming and tracking client submitted SOA tasks (requests). RRS feed

  • Question

  • I have a SOA dll.

    I submit requests to the cluster using DurableSession/BrokerClient. 

    I'd like to know

    1) if there is a way I can set the task name when i submit the task via broker client's submit request? can i do it from within the SOA Dll itself? (using CCP_TASKID? any example out there?). Either way, the job would already be in Running state.. is it possible to set the task name when a job is in running state?

    2) what is the max. length that can be set for  a task name?

    3) can i monitor the task execution (exact workstation node name etc) 

    4) # of actual tasks submitted via broker client is not same as the number of tasks shown in job manager for that job. I'd like to be able to see the actual progress of tasks in my job (similar to the 'Requests' shown in job manager). someone on web pointed out that ISchedulerJob.GetCustomProperties() will have the requests in faulted/completed etc states but I'd like to know which of those exact requests are completed/faulted etc


    • Edited by SRIRAM R Monday, July 4, 2016 2:52 PM
    Monday, July 4, 2016 2:50 PM

All replies

  • For SOA job, the task is just the execution instance for your service (A task will instantiate one SOA service host which will load your SOA dll) and all the requests submitted from your client will be routed to those service host. Thus:

    1. The task name in your SOA job won't help you a lot. Could you tell us why you want to set the task name? -- What you want to achieve through a task name?

    2. Task name should be around 256

    3. When you say monitor task execution, are you want to know where the task is running? If that's the case, you can view the job in the job manager GUI, view tasks page, select a task, you will see "Allocated Nodes" which will tell you whether the task is running.

    4. For SOA job, you need understand the difference between "Task in the job" and the "requests in a session". A session maps to a job and associate with a service (a configuration file, and a SOA service assembly). The tasks in the job will be auto-expanded based on the number of resources allocated to the job (thus session). And all requests will be send to those running tasks (SOA service instances) for calculation. When resources grow in the job, the task number will grow, when a resource is taken away by the scheduler, the running tasks will be finished.

    Qiufang Shi

    Tuesday, July 5, 2016 1:11 AM
  • To be very specific, I'd like to track the "Requests" (internally they are mapped to tasks?) programmatically - The summary view shows "Total Requests", "Succeeded", "Failed", "Calculating" and "Incoming". I'd like to dig deeper a level and see where exactly they are run (node information)

    In my use case, each of these requests are executed by an instance of the SOA dll on one of the workstation nodes via HPCservicehost32.

    Some of these requests could be long running. I'd like to, from time to time, query the requests that are still running and report to the user through my custom app. The only way I can cross reference them is by 'naming' them and hence the request of naming the tasks.

    One way, I thought, was for my SOA dll to pull the CCP_TASKID (or something similar) and name the task. And later, a different client will pull the ISchedulerJob, connect using the Job/SessionID and get the task(s) and see their status. Just want to ensure I can do it before I take that approach.

    Tuesday, July 5, 2016 3:11 AM
  • Hi SRIRAM R,

    For monitoring SOA request/task execution, besides the progress view for Total/Succeeded/Failed/Calculating/Incoming requests of the SOA job on the job view in the job manager GUI, you may also enable the Message Level Tracing for the specific SOA service, and then when the SOA service is running, choose 'SOA Jobs' tree view under 'Job Management' in the job manager GUI, right click on the SOA job and choose 'View Message Details', there will be a pop up window showing the detailed tracing info for each SOA request including the message id, status, timestamps, target machine and task id etc.


    Yutong Sun

    Tuesday, July 5, 2016 3:37 AM
  • Yep. Am aware of that. But,

    1) how do I programatically query that info? (messsage id, task id, response type, dipatch time and response time and any associated exception details)?

    2) how can map/correlate of those "messages" to my "actual" requests? 

    3) the message details does not seem to have the node info.

    With this approach, if I can write a Verbose message from my SOA Dll with the machine/node name, I'd miss out on my 'Critical' messages by this method.

    Or am i missing something here?

    • Edited by SRIRAM R Tuesday, July 5, 2016 3:49 AM
    Tuesday, July 5, 2016 3:49 AM
  • 1) We don't have public API to query message level trace info. 2) To map the messages with requests, you may specify the 'messageId' when sending the request with the BrokerClient. 3) the message details have a 'TargetMachine' property which is the name of the node on which the request is proceeded.

    And for your scenario, is there a requirement for the Admin to report back to the User the SOA message details? I suppose the User who owns the SOA client for sending requests and getting responses should be able to know some of the message info in real time?


    Yutong Sun

    Tuesday, July 5, 2016 5:56 AM
  • Just want to ensure you are referring to "userdata" parameter below when you say "messageId" when sending the request with brokerclient

    publicvoid SendRequest<TMessage> ( TMessage request, Object userData )

    If it is, I was looking for a way to set this "userdata" as 'Task instance' name - Perhaps it's not possible.

    What I did was

    1) Get CCP_TASKID and CCP_TASKINSTANCEID in my SOA dll code which map to actual Requests. When concatenated, I get the 'actual'

    task instances that were used in job manager under task details (and also map to Task Id under Message Details for my SOA job)

    So, Task details may have a TASK_ID=1 and several instances (say, 1...20) under it but if the actual ones that were used to

    run my requests have a TASK_INSTANCEID of 3,4,5 and 7 (ie., 1.3, 1.4, 1.5 and 1.7)

    2) Insert these CCP_TASKID.CCP_TASKINSTANCEID and NODE name into a database from the SOA dll.

    3) Elsewhere, in a custom written app, query job using


    This has an enumeration of SchedulerTask using which I can get to the exact taskinstance by cross referencing with values from step (2) above.

    Wish there was a way in HPC job manager UI as well to cross refernce my requests to the exact CCP_TASKID.CCP_TASKINSTANCEID in either message details view or task details view.

    Tuesday, July 5, 2016 4:25 PM
  • No, it is 'messageId' parameter instead of 'userdata'. See the method signature below. This is a new parameter we added in HPC Pack 2012 R2 Update 2 (version: 4.4.4864), you need to upgrade the SDK to that or a later version to set messageId.

    public void SendRequest<TMessage>(TMessage request, object userData, UniqueId messageId);

    There are already node name and task id info in the message trace detailed view in HPC cluster/job manager GUI as below,

    MessageId : 041d7061-7cd5-4dcb-85d7-0717e9b511f3

    Target Machine : HPC-3232516

    Task Id : 18.1.6

    If you would like to persist these info in database for each request in the service code in real time for other purposes, it is OK to use the task environment variables like CCP_TASKID and CCP_TASKINSTANCEID and COMPUTERNAME. Just note this message tracking may bring extra effort for the service and consider if there is a real need to do so.


    Yutong Sun

    Wednesday, July 6, 2016 1:53 AM
  • Thanks!

    Now, does the "userdata" get stored somewhere in the message details? i know it's not visible in the Job manager UI, but can a task (or tasks) be queried using a userdata?

    For eg., ISchedulerJob.GetTaskList(userdata,null,true) 

    Wednesday, July 6, 2016 2:20 AM
  • UserData can be used to correlate the response with the request. After setting it when sending the request, it can be retrieved by the BrokerResponse<TMessage>.GetUserData<T>() call after the response is received.


    Yutong Sun

    Wednesday, July 6, 2016 4:16 AM