My thoughts on "tasks committed to other platforms" . I think in the past we had a problem of long periods of time where it would get stuck in this status and none of us would get any WUs.
The techs have been playing with this, and I think there is a cycle of new WUs and resends. I think this is a feature, and not a bug. Why do they need to do this?? is it to ensure resends get a chance to go out? is it to pause the new WU generators for load reasons? is it to keep the size of the db under some limit?? I have no idea.
Just when I think things are broke, the system starts sending out new WUs again. It is hard for me to judge lately.

This is probably a weekend outage though.

update: no sooner do I post this then I get fresh MCM and ARP. I think it is just cycles.

Unixchick,

I'm inclined to agree that the intervals of no new work are usually the result of something planned or calculated on the fly -- unfortunately, the underlying infrastructure still seems to be playing up occasionally (including today!) so it's also possible that sometimes something relevant to this stops working and needs an [automated?] restart.

I seem to recall reference to something that tried to moderate new work based on work already out there, so that's one possibility. (If that is what they are doing, I think it is still in need of tuning if [almost] none of the longer intervals with no new work but not much sign of "other platforms" messages are due to service node issues!)

A case could also be made for watching the quantity of pending resends (and the lowest WU numbers associated with them) and stopping new work feeding if it seemed likely that there might be a build up of "Waiting to send" -- recall that when that was happening a lot, retries were getting out but they all tended to have higher WU IDs...

Another possibility might be that something monitors the platforms to which resends might go; if a huge backlog starts to build up for one or more platforms, slamming the brakes on new work might enable those resends to clear out faster. (Dealing with possible backed-up Android retries cropped up in the MCM1 forum very recently, with an attempted explanation of why WCG might not want to send tasks for a single WU to a m!x of platforms! I'm still half-expecting the user I answered to come back and argue...)

On the previous page of this thread I posted a link to a very old thread where there was reference to a problem with a big backlog of retries... I found it when I was looking for references to that "high load" message.

On a different note, but related to retries: the 653 MCM1 WUs for which I processed work on the 20th had 31 WUs that needed retries, and 15 of them were because an initial task failed "can't write init file" - sadly, all of those appeared to be for the same system! I struggle to understand how that can happen without the user being aware unless they never check their system. That's far from the only instance of individual systems appearing to have repeated instances of a single type of failure; stuff happens...

(And, for what it's worth, 4 of my retries for yesterday ended up Server Aborted, another recent topic here!)

Cheers - Al.

I've had the same problems, but now 0800 local time(UTC+2) all pages are loading without any problems!

Thank You staff for fixing this late evening/early night (Toronto time!)🥱

Hans S.

ARP1_0030777_147_0.
No resends here.

Cheers

Thanks for the info. I'm really happy to see ARP sending out fresh WUs. Looks like we are getting close to finishing gen 147