Bug 1730681 - DRb::DRbConnError: too large packet 2147680256
Summary: DRb::DRbConnError: too large packet 2147680256
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.9.7
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.14
Assignee: Tina Fitzgerald
QA Contact: Niyaz Akhtar Ansari
Red Hat CloudForms Documentation
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-17 10:48 UTC by Niladri Roy
Modified: 2019-12-09 21:21 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-12-09 19:55:33 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)

Description Niladri Roy 2019-07-17 10:48:35 UTC
Description of problem:
Service provision fails with below error
DRb::DRbConnError: too large packet 2147680256

Version-Release number of selected component (if applicable):

How reproducible:
First occurrence at Cu env

Steps to Reproduce:
1. Provision a service

Actual results:
provisioning fails with below error
DRb::DRbConnError: too large packet 2147680256

Expected results:
provisioning should complete successfully

Additional info:

Comment 6 Khushbu Borole 2019-11-27 09:30:42 UTC
Hello All,

I am reopening the bugzilla for few queries from the CU on the issue.

We understand this is not supported due to the custom code but answers to the below queries will be appreciated

- How to identify which message exceed such limitation ?
- Provide documentation about such DRB message and such limitation
- What would be the best practice to implement in our custom code to avoid such DRB message limitation?
- Is there any possibility to increase such DRB message limitation from 25Mb to 50Mb for instance ? what would be the side-effect of such change ?

Looking for the reply asap.

Thanks in advance.

Comment 10 Tina Fitzgerald 2019-11-27 18:20:16 UTC
Hi Niladri,

We're going to need some time to look into this further.

I'm setting up an internal meeting to discuss this on Monday, and will send an update afterwards.

In the meantime, if the customer is agreeable to trying a workaround, I would ask them to use the server affinity Automate setting to see if the problem goes away when they're staying on the same server.
If so, can you ask them to add the following line to one of their custom Automate provisioning methods:

$evm.root['ae_retry_server_affinity'] = true

This setting should be set anywhere they're doing a retry in the state machine. Since there could be many places where retry is set, they could instead set it at the beginning of provisioning for the entire provision.

Let me know if you have any questions. 


Comment 12 Tina Fitzgerald 2019-12-02 15:26:56 UTC
Hi Niladri, Khushbu,

Can we setup a call with the customer today?


Note You need to log in before you can comment on or make changes to this bug.