For test tried to publish a simple change in a doctype and I am getting below error in Report step:
Error while processing settingsPush - (export/Report/0/) - Remote Error: InternalServerError : An error has occurred. (/umbraco/uSyncReceive/uSyncReceiveApi/ReportPackFolder) Exception: [pack folder : C:\local\Temp\UmbracoData\dbfdf77562ed36ad90ad6cd1bc92141a\uSync\receive\ba09b57f-7808-4ce5-8c56-b313885c9a81 does not exsit when it should]
I am pushing from localhost to our test instance on Azure.
No 1 - reason we see this is load balancing (azure scale out). the requests all have to go to the same server (as recommended by umbraco - you can only have one back office server at any given time). if they don't then mid push the server can flip and then the files are missing.
So much so. this is in fact the code triggering that error.
Other possibilities are that something intercepted the upload of the data from the source to the target. and it never infact had anything to unzip - example are firewall rules or proxies that are stripping application/zip media types (the data is sent across the wire zipped up with this mime-type).
Our test envs are single instances and not using load balancing.
I disabled VNet route (WEBSITE_VNET_ROUTE_ALL) on target server and now I am getting another error message again in report step:
Remote Error: MethodNotAllowed (/umbraco/uSyncReceive/uSyncReceiveApi/ReportPackFolder) Content: [The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.]
that looks like the result of a firewall / proxy converting a post request into something else ?
but its odd because there are other POST methods called before this one, (e.g the one that actually sends the files between the servers). 🤔
I would take a look at any configuration you may have that is altering requests, because this could also be the cause of the first issue - if the request is in someway getting altered or internally rejected then the pack file might never arrive (so it would be missing), which would also explain the first issue.
As suggested I did some more investigations and realised there was more than one deployment slot for my test environment, so I assume that causes confusion with load balancing.
Now I connected to another test instance with only one slot and now I am getting timeout issue as below:
Is there anywhere I can extend the timeout on target server for this issue?
There are a couple of timeouts you can extend in the web.config - i think this one is the request timeout (https://www.techcartnow.com/increase-timeout-asp-net-application/) - but beware on azure there is a hard limit of i thing 240seconds on all request.
usync is paging the requests in an attempt to try and avoid timeouts when things can take a while, and you can change this page size in the uSync.publisher.config
the default is a page size of 25 - the lower the number the fewer items per request (and the less chance of a timeout) - so you can reduce this too if it helps.
Error during pushing to server
Hello,
I am using Usync Complete trial version 8.11.8.
For test tried to publish a simple change in a doctype and I am getting below error in Report step:
Error while processing settingsPush - (export/Report/0/) - Remote Error: InternalServerError : An error has occurred. (/umbraco/uSyncReceive/uSyncReceiveApi/ReportPackFolder) Exception: [pack folder : C:\local\Temp\UmbracoData\dbfdf77562ed36ad90ad6cd1bc92141a\uSync\receive\ba09b57f-7808-4ce5-8c56-b313885c9a81 does not exsit when it should]
I am pushing from localhost to our test instance on Azure.
Anyone has any suggestions?
Umbraco version: 8.16.0
HI Amir,
No 1 - reason we see this is load balancing (azure scale out). the requests all have to go to the same server (as recommended by umbraco - you can only have one back office server at any given time). if they don't then mid push the server can flip and then the files are missing.
So much so. this is in fact the code triggering that error.
Other possibilities are that something intercepted the upload of the data from the source to the target. and it never infact had anything to unzip - example are firewall rules or proxies that are stripping
application/zipmedia types (the data is sent across the wire zipped up with this mime-type).Thanks Kevin for quick response.
Our test envs are single instances and not using load balancing. I disabled VNet route (
WEBSITE_VNET_ROUTE_ALL) on target server and now I am getting another error message again in report step:Remote Error: MethodNotAllowed (/umbraco/uSyncReceive/uSyncReceiveApi/ReportPackFolder) Content: [The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.]
Hi Amir,
that looks like the result of a firewall / proxy converting a post request into something else ?
but its odd because there are other POST methods called before this one, (e.g the one that actually sends the files between the servers). 🤔
I would take a look at any configuration you may have that is altering requests, because this could also be the cause of the first issue - if the request is in someway getting altered or internally rejected then the pack file might never arrive (so it would be missing), which would also explain the first issue.
Hi Kevin,
Again thanks for your quick response.
As suggested I did some more investigations and realised there was more than one deployment slot for my test environment, so I assume that causes confusion with load balancing. Now I connected to another test instance with only one slot and now I am getting timeout issue as below:
Is there anywhere I can extend the timeout on target server for this issue?
Hi,
There are a couple of timeouts you can extend in the web.config - i think this one is the request timeout (https://www.techcartnow.com/increase-timeout-asp-net-application/) - but beware on azure there is a hard limit of i thing 240seconds on all request.
usync is paging the requests in an attempt to try and avoid timeouts when things can take a while, and you can change this page size in the uSync.publisher.config
the default is a page size of 25 - the lower the number the fewer items per request (and the less chance of a timeout) - so you can reduce this too if it helps.
is working on a reply...