Timeout on long running WR via API call

Pascal_SSC · 2025-07-10T12:23:30+00:00

There was an error rendering this rich post.

I can run a certain WebReport from the front-end browser interface of Content Server and it takes about 15 minutes and completes properly, whether regular run or in background. However, if I run the same WR from an API call in PowerShell, there seems to be a timeout and produces this error:

"Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a receive."

If I change the breadth of the WR so it only take a couple minutes, it will run fine from API.

Note that the length of the WR depends on the amount of items it processes to then be added to a CSV file output.

I'm wondering if anyone knows if there are any settings in Content Server, or the machine running the API, or in the script itself, that might affect this timeout. Or would you have any other ideas?

Thanks,
Pascal

Find more posts tagged with

Comments

appuq

If I change the breadth of the WR so it only take a couple minutes, it will run fine from API.

what does that statement mean?

Pascal_SSC

The WR scans a folder (determined by parameter) and outputs a CSV file of all documents throughout the sub-structure. Picking a folder with a large amount of documents makes the WR take longer. So I can make sure it's a shorter running WR by picking a smaller folder. It does the same process on the folder.

I'm getting indications that maybe it's something to do with PowerShell, which I'm still new to, but I'm still curious to know if the use of Content Server API specifically has something to do with it.

appuq

If you are passing an otcsticket, switch it to otdsticket if the situation improves, then it could be auth-related. When you do something with a WR and aren't completely scheduling the distribution yourself, a single ot thread is doing your bidding.

BTW, when you use the restapi with otdsicket and internal swap happens with otcsticket if no one has tampered with the otds there, its ticket lives for 4 or 6 hours, not sure what it is now and you can be rest assured that it is loadbalancer safe and session safe.

The restapi is a specialized use of a regular request handler; nothing too complicated about it.

I could be wrong if you say your longer running wr runs fine if you run it within the gui.