When is a branch too big?
In our current project, we're using branches and Deployment Manager to merge and deploy branches. We ran into a problem when we tried to merge one specific branch. Other branches didn't have that and were merged smoothly and without any issues.
The logs showed a Timeout issue when calling certain pipeline services. As far as we can say, the corresponding Connector rule has a timeout of 30 seconds which can't be changed or controled through DSS or suchlike. This oob Connector rule is a final rule.
Our branch was quite big in terms of number of rules: more than 350 rules. Apparently too big! Too many rules for this service to come back with a response within the timeout.
We moved 100 rules to a second branch. Now we were able to merge both branches.
I agree that this branch had a quite unusual number of rules. And I agree that we should prefer small and specific branches. On the other hand, sometimes it makes sense to put quite a number of field values, icons or other rules into one big branch.
So I'm wondering why we cannot configure the timeout. Has anybody else already had the same issue? What do you think?
***Edited by Moderator: Pallavi to change content type from Discussion to Question***
Updated: 10 Aug 2020 6:31 EDT
Pegasystems Inc.
US
Could you include the error message that you're getting on the Deployment Manager side? Is it "Maximum attempts reached" or something like java.net.SocketTimeoutException?
The merge process happens in two stages using the out-of-the-box Pega APIs:
- POST /branches/{ID}/merge which queues the merge request and returns a merge request ID almost immediately and won't take longer based upon the size of the branch. If you're getting a SocketTimeoutException at this point, it's probably some sort of network issue. I've never seen an issue where generating this unique ID takes more than a second. My experience is that it happens so fast that I question if it worked at all.
- GET /merges/{ID} which checks in on the status of the merge. This will retry a number of times before timing out over the course of minutes. The number of retries is 10 and it waits 5 seconds between retries. If it takes longer than 50ish seconds Deployment Manager will write "Maximum attempts reached" but the merge on the dev server will continue normally.
This sounds like you had a network issue, but I'd be curious to find out what error you were getting.
Pegasystems Inc.
DE
I'm trying to get the logs from that time. I'm not sure for how long they are kept. I don't have access to the servers myself, I have to ask our partner, they are running the infrastructure.
Cheers Armin
Pegasystems Inc.
US
@schma Thanks for the logs.
I'm seeing that the import is going fine: Total instances in archive: 860 Instances imported: 842 Instances skipped: 18
I'm seeing that the pxGetMergeConflicts kicks off, but when trying to return a value you're getting a socket timeout
ERROR Rule-Connect-REST.Pega-Int-Pipeline.pzPostTaskStatus DMAppAdmin - HTTP connect execution failure: java.net.SocketTimeoutException: Read timed out
This suggests to me that the Dev system is having a hard time connecting back to the Deployment Manager system with the conflicts results.
Vodafone India Ltd
IN
Hi Armin,
As we discussed over the call, this is only happening for this branch and other branches are merging fine. Can you split this branch into smaller ones to see if the issue with size of branch?
Thanks,
Srikanth
Pegasystems Inc.
DE
Hi Srikanth,
yes, that's what we did. We moved 100 rules to a second branch and merged the remaining 250+ rules. That worked out fine. So threshold for our branch was between 250 and 350 rules.
Cheers
Armin
TATA Consultancy Services Ltd
GB
I am having the same issue even for 75+ rules. Branches with less rules are getting merged successfully but with more rules this issue is occurs. how did you solve this issue? just splitting the number of rules? Logs
I am having the same issue even for 75+ rules. Branches with less rules are getting merged successfully but with more rules this issue is occurs. how did you solve this issue? just splitting the number of rules? Logs
2020-12-29 12:02:34,797 [ PegaRULES-Batch-92] [ STANDARD] [ ] [vOpsFoundationV1:4.7] ( connect.rest.RESTConnector) ERROR Rule-Connect-REST.Pega-Int-Pipeline.pzPostTaskStatus DMAppAdmin - HTTP connect execution failure: java.net.SocketTimeoutException: Read timed out 2020-12-29 12:02:34,799 [ PegaRULES-Batch-92] [ STANDARD] [ ] [vOpsFoundationV1:4.7] ( connect.rest.RESTConnector) ERROR Rule-Connect-REST.Pega-Int-Pipeline.pzPostTaskStatus DMAppAdmin - Rule-Connect-REST: https://XXX.XXX/prweb/PRRestService/cicd/v1/task/deploybranch/status?FlowName=pxGetMergeConflicts&FlowActionName=pzPauseTask - Caught unhandled exception: java.lang.RuntimeException: java.net.SocketTimeoutException: Read timed out - java.net.SocketTimeoutException: Read timed out 2020-12-29 12:02:34,800 [ PegaRULES-Batch-92] [ STANDARD] [ ] [vOpsFoundationV1:4.7] ( internal.mgmt.Executable) ERROR Rule-Connect-REST.Pega-Int-Pipeline.pzPostTaskStatus DMAppAdmin - Exception 2020-12-29 12:02:34,800 [ PegaRULES-Batch-92] [ STANDARD] [ ] [vOpsFoundationV1:4.7] (nvoke.Rule_Connect_REST.Action) ERROR Rule-Connect-REST.Pega-Int-Pipeline.pzPostTaskStatus DMAppAdmin - com.pega.pegarules.pub.services.ConnectorException: Caught unhandled exception: java.lang.RuntimeException: java.net.SocketTimeoutException: Read timed out 2020-12-29 12:02:34,801 [ PegaRULES-Batch-92] [ STANDARD] [ ] [vOpsFoundationV1:4.7] ( internal.mgmt.Executable) ERROR DMAppAdmin - Exception