Issues with uploading to 128.252.203.1 & .9

[Eagle]

It's a pitty to hear that - especially since I thought that hosting it cloud-wise would solve such problems while in reality, it seems to cause even more such problems..

Thanks for the detailed insight, though. Very much appreciated. If I can be of any further help towards my WU problems, just let me know!

[bruce]

*.1 (aka farclas) is having some kind of hardware problem that is being addressed and is, in fact, offline until it can be resolved.
*.9 (aka islay) which has some projects on - but I think the issue is rooted back to farclas being down for the moment as a CS rather than islay being an issue. This should be resolved now.

A project's Servers are assigned when the WU is originally assigned and I don't think there is a way to reassign either of those IPs. All the information is attached to the WU that's in your client.

[Eagle]

Thanks for the heads-up, but since I'm now over 60 (!) WU not being able to return to one of those two, why's not change to the WU _prior_ to transmission to clients like mine done already?
I do understand the issues (Thanks again for your insights!), but I struggle understanding why no interim solution is applied to prevent further issues.

[bruce]

Thanks for the heads-up, but since I'm now over 60 (!) WU not being able to return to one of those two, why's not change to the WU _prior_ to transmission to clients like mine done already?
I do understand the issues (Thanks again for your insights!), but I struggle understanding why no interim solution is applied to prevent further issues.

When the WU is assigned, the WorkServer is already predefined. At that same time a CollectionServer is designated. If something happens to the CS while you are working on the WU, the IP addresses have already been imbedded in the WU and can no longer be changed.

No more WUs should be issued pointing to that failed CS but some have already been assigned.

[Eagle]

I do understand that, may I suggest that a change is implemented, allowing to modify a WU's assigned CS on the _server_ (!) side _after_ such problems arose, not directly helping "victims" like me, but other participants who are about to receive this exact WU so that they're not suffering the same issue?

On a more wider roadmap, maybe implement kinda "backup CS" for such situations? After all, even DNS providers commonly provide a primary & secondary server IP for the exact same reason..

[bruce]

modify a WU's assigned CS on the _server_ (!) side

The Work Server will stop distributing WUs that are pointing to a specific CS and point to another CS (assuming there is a functional one) for future WUs but the IP address is distributed inside the downloaded package for the WU. Nothing can be done at the server level to the WUs which have already been downloaded by somebody.