Job .xml files limit ?

[Quentin Mirioni]

Hello all,

It's been a couple of months that we've been changing quite a lot our way to deal with environments in our rr renderfarm.

I'm extensively using the newer rrEnvList parameter to generate environment within the pipeline to drive different jobs.

It works well but I've been seeing issues with jobs not being fully complete (settings wise) in RR Control when the size of the rrEnvList is large.

As per my tests, I was able to have a rrEnvList of about 3 900 characters before it wasn't taken into account correctly anymore.

Sometimes the job had half of the settings it was supposed to have.

We also have some custom settings in our jobs' xml. customA, customB, customC, etc which doesn't seem to help keeping the size of the job xml small.

Until then, I managed to work around this by reducing our envs to the strict minimum but this is not possible anymore.

I tried to submit a job today without success :

Total xml length: 6 021

rrEnvList length: 3 272

customA length: 1 441

customA inside the job is just empty after submission.

if I remove the rrEnvList, customA is there and works fine, and vice versa.

What is the limit of xml job file that we can submit ?

And is there a way to work around this cleanly ?
Without changing the way we pass environments inside the job xml if possible.

We are using version 8.3.03b on Linux Centos7

Note, I saw and read a similar thread with the rrEnv files limit, but it seems to be a slightly different problem here.

Thank you,

Quentin

[RR, Schoenberger]

Hi

 

The custom variable buffer has a size of 4000 ansi chars (or 2000 unicode).

It conains the env list as well.

I would recommend to use some helper env vars to reduce the size of your lines.

Like <CompanyProjectRootFolder> or a custom define one.

 

e.g.

PipelineRoot =<CompanyProjectRootFolder>

PipelineRoot= //fileserver/pipeline

 

And then use it:

HOUDINI_PATH= <PipelineRoot>/pluginXY;<HOUDINI_PATH>

 

 

regards,
Holger Schönberger

 

Please use the rrKnights Tavern
or our support system for new questions.

[RR, Schoenberger]

PS:  Note that if you use the same pipeline folders in all projects, then you can use <CompanyProjectRootFolder> in the main houdini__inhouse.rrEnv as well.

[Quentin Mirioni]

Hello,

Okey, thanks for your answer.

Indeed, I can gain a bit of chars by using extra helper env vars to reduce the size, about 500chars at first glance but :

- it complexifies our processes

- it would not solve the issue as the custom values would still be > 4 000 for this specific example (if I understood correctly that the rrEnvList and all custom attributes are included in this buffer)

- we will have the same problem in a couple of weeks once production grows and we must add envs in the rrEnvList or extra custom arguments to the pile.

1. Any chance that this buffer is increased in more recent version of RR ? We are planning the switch to RR9 in the upcoming weeks.

2. Would removing the rrEnvList and replacing it by a rrEnvFile path would reduce the buffer ?

We could generate and write the custom rrEnvFile to disk before the job is submit.

Trying to find the best compromise here,

Thank you,

Quentin

[RR, Schoenberger]

Hi

 

>1. Any chance that this buffer is increased in more recent version of RR ? We are planning the switch to RR9 in the upcoming weeks.

The database should not change while we release 9.0.xx versions.
And 9.1 is not scheduled yet.

 

>2. Would removing the rrEnvList and replacing it by a rrEnvFile path

An rrEnvfile is just a link to the file.
The file can be any size as it is not saved within the RR database.

 

 

Perhaps you can upload some of your .xml files that I can take a look

at your custom vars and envlist?
Perhaps I see some parts that can be optimized with the help of rrEnv possbilities.

www.RoyalRender.de/upload_r.php  (upload is not public)

 

 

 

PS: Note that you can mix different files/settings:
Example:

1) Global rrEnv file

The Houdini.rrEnv  ( in your case Houdini__inhouse.rrEnv) file sets the env var RR_HTOA_ROOT

if it is empty.
And RR_HTOA_ROOT is then used to define all env vars for the HtoA plugin.

 

2) rrEnvfile

By default the file location is set to the projects root on your fileserver.
Which means all jobs of a project use the same env file.
Companies use it to change the RR_HTOA_ROOT to the version of the project.
(and RR_HTOA_ROOT is then used in 1 again)

 

3) rrEnvList

These settings are used if there are special jobs that require their own settings.
Settings that are different from all other jobs of the project.

 

 

PPS:
Note that you can use conditions in rrEnv files/lines as well.

Examples:
If RR_HTOA_ROOT not set, then set default path

If Renderer=Arnold then …

If Houdini-Version<19 then…

[Quentin Mirioni]

Hello,

Thanks for the clarification of all options available!

It looks like we should have gone with the rrEnvFile option from the beginning.

rrEnvList is just not meant to push big environments with jobs, only small overrides.

We adapted the way to send jobs by generating on the fly a custom rrEnvFile right before submitting it.

Without the environment, we will always be under the 4 000 chars.

Maybe this technical limitation of the rr database could be added to the help ?

Also, a clear warning/error message in the submitter console stating that the custom buffer was full and that some data was ignored could be useful.

I probably hit this limit for years and had weird issues because of this without even knowing it.

Here, we do not make use of the configs directly hard coded inside the RR server.

Mainly because we need all our processes to work with multiple projects, in different facilities, external partners, sometimes with overrides, dev environments,...

Therefore, we try to remove as much dependencies/config as possible from RR itself.
Probably not something many studio do so... it leads to edge cases like this.

We can consider this solved, thank you !

Quentin

[RR, Schoenberger]

>configs directly hard coded inside the RR server.

>as much dependencies/config as possible from RR itself.

That’s why I mentioned that you can add conditions.
The job settings switch a project rrEnv or the main RR rrEnv.
Within a project, jobs of the same render app use 95% the same environment.
But as you are now using the rrEnvFile per job, a per-project file is not possible any more.

> I probably hit this limit for years and had weird issues because of this without even knowing it.

In the cases we have seen at customer sites, I think it was always less than 2000.

That’s why 4000 seemed to be sufficient.

It will be added to the help files.

Perhaps the rrSubmitter should warn as well…
These little things no dev thought about.
:-)