Hi,
When a 503 error appears in the Service Logger/Browser console it appears that the Service stops running but the job isn’t marked as an error and we aren’t able to start a new job due to “no concurrency” being enabled. Is this intentional? It doesn’t seem logical to have a stopped job occupying the service for the reminder of set job timeout. As 503 most likely are due to insufficient resources (503 Proxy error - service, ECONNREFUSED. What does it mean? - #2 by aaron) we’re unable to create some logic ourself for handling this. Any suggestion on how to stop/handle a Service that are running when a 503 appears?
Hey,
Have had this issue before and I think its been reported (it should reset the concurrency check). However the workaround we used is to make sure that the service is running at a limited set of data using a limit on the read to. And then scheduling the job with enough space to not run at the same time and ensuring that it runs often enough to complete the dataset per iteration.
In this case you would need to implement some tracking of which object has been run or not, and reset this between each full run.
Is that relevant to your case? 
1 Like
Hi Sondre,
Great input there - thanks!
In our case, we’re not able to limit the number of objects being read as it’s the combination of all objects that produces the unique output. However, we see some logical blocks that, to some extent, can be separated from each other, and for these cases, we can use the tracking logic that you suggested. Implementing this tracking into an orchestrator of some sort seems to be the way to go.
This doesn’t directly resolve the “no concurrency” issue but helps us handle it more elegantly until Appfarm comes up with some best practices (or a fix?) for these scenarios.
1 Like