Feature #2040
closed
Provisioning system timeout - Execute provisioning synchronously from long running task is stucked
100%
Description
When provisioning occurs from other long running task (e.g. when business role definition is removed), then provisioning is stucked (provisioning operation stays in CREATED state) and long running task is stucked too.
Related issues
Updated by Radek Tomiška about 4 years ago
- % Done changed from 0 to 10
I created business role with ~700 subroles with merge attribute specified (two systems - table + vs).
I've tested scenarios with remove / add composition simultaneusly, when provisioning is processed, when new roles are asigned to users etc.
I tried to delete provisioning queue simultaneously, when provisioning request is created / executed / canceled - related to #2033, quere is deleted immediatelly without a issue.
I'm not able to reproduce the issue on product for now - LRT and events are green.
I'll continue with try to find some synchronized block, which can affect provisioning queue this way ...
Updated by Radek Tomiška about 4 years ago
- Related to Defect #2033: Provisioning queue cannot be deleted added
Updated by Radek Tomiška about 4 years ago
- Related to Task #490: Timeout to system connection added
Updated by Radek Tomiška about 4 years ago
- Related to deleted (Defect #2033: Provisioning queue cannot be deleted)
Updated by Radek Tomiška about 4 years ago
- Related to Task #584: Dealing with connection timeout on network added
Updated by Radek Tomiška about 4 years ago
- Tracker changed from Defect to Feature
- Status changed from In Progress to Needs feedback
- Assignee changed from Radek Tomiška to Vít Švanda
- % Done changed from 10 to 90
After we found out the source of issue was in project infrastructure (thx all for help with debugging), I tried to think :) about ... how to improve provisioning timeout handling in IdM.
I've added new default ~ global configurable provisioning timeout, commit (in branch rtomiska/2040-provisioning-timeout):
https://github.com/bcvsolutions/CzechIdMng/commit/b1522594e2acc5033f4c84cbbc345a2b2afaa20a#diff-31ba6e91fd489b097e36b44e0f7db53f
This should help to know, what happen and what target system should be fixed. It covers all use cases (I hope so I didn't forget some) - sync (passwords) vs. async provisioning (asynchronous target system), all tests are blue.
It's mergable to lts, but we can discuss, if this improvement can be added into lts version and how long the global timeout should be (3 minutes by default now) ...
Note: Provisioning timeout can be configured different way by remote server (currently supported) / or by connector options (not supported now), but I don't wanted to depend on this timeouts are configured properly ... so I've added global timeout, which should be configured higher than remote server or each connector timeouts.
Could you provide me a feedback, please (I'll create a documentation afterwards after feedback approvement)?
Updated by Radek Tomiška about 4 years ago
- Target version changed from Rhyolite (9.7.15) to 10.2.0
Updated by Radek Tomiška about 4 years ago
- Related to Task #1837: Implement thread rejection policy for LRT pool added
Updated by Radek Tomiška about 4 years ago
Updated by Radek Tomiška about 4 years ago
I merged feature into develop - #1837 is implemented.
Updated by Vít Švanda about 4 years ago
- Subject changed from Execute provisioning synchronously from long running task is stucked to Provisioning system timeout - Execute provisioning synchronously from long running task is stucked
- Status changed from Needs feedback to Resolved
- Assignee changed from Vít Švanda to Radek Tomiška
- % Done changed from 90 to 100
I did review and test. Provisioning timeout works fine for my testing. Thanks for this feature which increase a IdM endurance.
Updated by Radek Tomiška about 4 years ago
- Status changed from Resolved to Closed