Receive timeouts from app.speckle.systems

Speckle Help Speckle (v3)
1

Hi folks.

We’re getting the following timeouts on a Receive() call to app.speckle.systems.

 System.Net.Http.HttpRequestException: Response status code does not indicate success: 524 (<none>).
    at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
    at Speckle.Sdk.Transports.ServerUtils.ServerApi.ResponseProgress(HttpResponseMessage childrenHttpResponse, IProgress`1 progress, CbObjectDownloaded onObjectCallback, Boolean isSingle)
    at Speckle.Sdk.Transports.ServerUtils.ServerApi.DownloadSingleObject(String streamId, String objectId, IProgress`1 progress)
    at Speckle.Sdk.Transports.ServerUtils.ParallelServerApi.RunOperation(ServerApiOperation operation, Object inputValue, ServerApi serialApi)
    at Speckle.Sdk.Transports.ServerUtils.ParallelServerApi.ThreadMain()
    at Speckle.Sdk.Transports.ServerUtils.ParallelServerApi.DownloadSingleObject(String streamId, String objectId, IProgress`1 progress)
    at Speckle.Sdk.Transports.ServerTransport.CopyObjectAndChildren(String id, ITransport targetTransport)
    at Speckle.Sdk.Api.Operations.RemoteReceive(String objectId, ITransport remoteTransport, ITransport localTransport)
    at Speckle.Sdk.Api.Operations.ReceiveImpl(String objectId, ITransport remoteTransport, ITransport localTransport, IProgress`1 internalProgressAction, CancellationToken cancellationToken)
    at Speckle.Sdk.Api.Operations.Receive(String objectId, ITransport remoteTransport, ITransport localTransport, IProgress`1 onProgressAction, CancellationToken cancellationToken)

The 524 response status is the timeout response from Cloudflare. The BATCH_SIZE_GET_OBJECTS is set to 10,000 objects per HTTP request in ServerAPI.cs. It appears that this isn’t returning in time before the Cloudflare 100s timeout threshold.

There currently isn’t a way to change this batch size to something smaller to avoid this. Ideally, the ServerTransportFactory.Create() in the SDK would be changed to allow setting this to a different value. An approach might be to have the constant as MAX_BATCH_SIZE_GET_OBJECTS with another value for a sensible minimum. The Create() function could then allow the setting of batch_size between these values if required.

This is currently a show-stopper for us. If there is a different way of avoiding this problem it would be great to know.

Tim Lewis.

1 Like
2

Hi @timlewis

Is it possible for you to share a link to the model with me (via a direct message to stay confidential)?

I’ll try and pull some server logs to see if I can see anything.

3

I did some searches through our logs, I think I have all the info I need to investigate @timlewis, no need to send any links.

I’ll run some experiments and coordinate with the team.

4

Thanks for jumping on this one so promptly Jedd. Really appreciate it.

5

Hi @timlewis

Just a quick update; we’re still working on it.

We’ve identified it to be a problem on our server side, that affects retrieving the object data of large models. We can consistently reproduce with some of the data on your project.

We’ve implemented a change already that we were hoping might solve this problem, however it were not sufficient and the problem appears to persists…

We’ll continue to search for a solution, I’ll let you know as soon as we have any updates.

6

If this is blocking you in the mean time; I might be able to suggest some some work-arounds that should avoid running into this problem.

If you’re interested; You might find success re-publishing the model through a different route. E.g. one of our desktop connectors, or via IFC files.

7

Hi @timlewis,

Earlier today, we pushed an update that hopefully should address the issue you’l reported with large Navisworks models.

I believe the fix only applies to new versions, so you will have to re-upload any affected models.