<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Would it be so hard to return no data and assign a new time some random number of minutes later? Only do this when the load is high... but that way you never need to worry about spikes.<br>
</blockquote>
<br></span>
Not all apps use the Suggested Time call. Those that do, aren't the problem.<br>
<br>
You're suggesting if they download during a busy time they just get empty results? Most of those folks wouldn't retry until the next day (same time).<br>
Eventually they'll be without data and notice. Sure that's one way to handle it, but it's a little drastic, IMHO.<br>
<br>
I can also not size the server to handle the spikes and let folks randomly fail. I'd rather not do that either.<br>
<br>
At SD we try to minimize support issues.. we all have day jobs.... and support takes a lot of time.</blockquote><div><br></div><div>I guess I am just looking at it from the Mythtv perspective.</div><div><br></div><div>If I run mythfilldatabase at 5pm ET via cron, and you were to return no data, but did set the suggested time call to 5:18... then mythfilldatabase would run again at 5:18... and I have no issue with that at all.</div><div><br></div><div>If you have other products who are using your service, but not respecting the suggested time call feature, perhaps this would serve to encourage them to do so? SD can certainly tell their customers that in order to use their service they must implement that feature... especially because it keeps costs down for everyone.</div><div><br></div><div>The only real issue I see is what if someone is troubleshooting and running their job manually and this happens... Perhaps the request could contain a flag to say "do not defer to a later time", and mythfilldatabase could use a switch to set that flag.</div><div><br></div><div>And perhaps I am way off base here.. just seemed logical to me.<br><br>Another possibility would be to queue requests and process them in the order queued. However it may be more difficult to implement since the client software would need to know to sit there idle waiting its turn.</div></div></div></div>