WAPI: PUT on /record:host - HTTP 500 Server Error

[#1]

Good day everyone;

We have a particular host record that contains a little over 4800 host aliases. Up until this point, we've been able to use a PUT request against the /record:host WAPI to add new aliases, but this stopped working last week and is now returning an HTTP 500 Internal Server Error.

Adding aliases to other host records work fine still, as well as adding an alias to this problem host via the GUI.

Is there a limit to how many aliases this WAPI request can handle?

Thank you!

  Richard

[#2]

I just ran one with 10k aliases, successfully adding the aliases to an existing host record.  It took about 10 minutes to process in the GM, after it was uploaded.  This was in a lab instance with limited memory.

Two thoughts come to mind. 

1) Possibly this is a client side issue, where the data for the put is truncated.  Or maybe your hostnames are that much longer than mine, and you;re hitting a kbytes limit and not a record size limit.  I used curl on osx.

2) how long does it take in your environment to finish processing?  What's CPU utilization look like, for the duration?  It is possible this isn't the best method, and instead unique CNAME records should be used.  I recognize there's value to keeping everything in one object, but at what cost?

[#3]

Thank you for your response.

I tried the same request - against a host record - in a clean QA environment and the request went through successfully, so the WAPI request is sound. This however does not account for utilization changes (disk / io / cpu / mem etc) of our production grid which constantly fails this request. Is there a way to get to the raw apache error logs on these appliances?  I'm making these WAPI calls with an automation platform and am able to reproduce the issue via PostMAN as well, but I will give it a try via CURL. (just as a process of elimination)

As far as your CNAME suggestion; it's definitely something I will bring up for consideration but for now, the current automated solution is based on requirements brought forward by our Network Engineering team so not sure if, or how soon, this can be done.

Thanks again for your feedback!