Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Can we use executor framework in plugin

Hi ,
I am working on creation of multiple child work item through plugin. Plugin can create multiple(40-50 work item) child work items while changing the state of parent work item but this will decrease the performance. 
Is there any way to increase the performance of plugin to create the work item. Is it good solution to use executor framework thread pool in plugin to create the work item. 

0 votes

Comments

Automatically generating 40-50 child work items is normally not a good idea.   Could you explain why you are doing that?

Hi Geoffrey,


My requirement is that I have configured one custom attribute of string list type in work item in that I am selecting multiple values. For each selected values it will creates some middle level and low level of child work items on run times while changing the state of work item. 
1. Each selected Work Item contains Middle level 3-4 child work item.
2. Each Middle level of work items contains 6-8 low level work items.

I tried it by simple work item creation logic using server api's but it will take 10-15 min if we selected 3 values in custom attributes.
I tried it using thread pool to create a work items but it will give some exceptions regarding database

Normally, a work item represents a minimum of 4 hours of work ... and decomposing a large work item is usually a creative process done by a human.  Could you give a specific example of the kind of work item you have in mind, and the kind of child work items that would be automatically generated?

Hi  Geoffrey,
I have a tree structure of the activities will be done for any particular component[Not RTC Component but part of product].  There are hundreds of similar components in the product that is represented by separate workitem  lets say W1. 
Our requirement is when user reaches to at particular state of the workflow in W1 some high level task with few low level tasks in each high level will be created and link to the W1 as child. So i try to change on the particular state it(RTC plugin) starts creating the tasks but taking too much time since as many as 30 tasks are being created so it is taking few minutes in saving the work item on that state. I am trying to implement this with threading so instead of these 30 tasks created by one thread, multiple thread will take less time. Although i didn't get any success in it by now. 

@anuragpatel153 RTC should be able to cope with that amount of work items.

Creating 50 children should take less than one minute and have no significant impact on performance.

Either your servers haven't been scaled as they should, or

The server-side script is not optimal. Excessive concurrent calls maybe?

The reason I've been looking for the motivation for this is that the main issue with automatically creating large numbers of tasks is not the initial cost of creating those tasks, but rather that this produces both system load (query results, plan loading time) and user load (somebody needs to assign ownership of the work item, estimate the cost of a work item, and transition it to through the appropriate states).   That is where the "at least 4 hours" recommendation comes from.    And if your leaf "tasks" do not require 4 hours of work, a common lighter weight approach is to use "approvals" as your light weight tasks, or work item properties (as is seen in the "checkbox" properties in some of the jazz.net work item types).

showing 5 of 6 show 1 more comments

Be the first one to answer this question!

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 6,131

Question asked: Nov 12 '16, 6:08 a.m.

Question was seen: 1,440 times

Last updated: Nov 14 '16, 2:59 p.m.

Confirmation Cancel Confirm