madhuneal / ppss

Automatically exported from code.google.com/p/ppss
0 stars 0 forks source link

Suggestion for special retry and/or delay processing #62

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. This is not a problem, it is a suggestion.
2.
3.

What is the expected output? What do you see instead?

If would be useful if ppss had a way for the "command" that ppss runs can tell 
ppss (via a special return code or other method) to do special things - for 
example:

* skip this ITEM completely (do not process it) and mark this item as skipped 
as a special form of success.

* temporarily delay processing this ITEM (i.e. move to next ITEM (if there is 
one) and get PPSS to make another pass through its input-file/input-directory 
to proces only the 'delayed' items.

What version of the product are you using? On what operating system?
2.85 on Linux (RHEL 5.5) x64.

Please provide any additional information below.

I know it sounds strange to as ppss to skip (do not process) an item that is 
already in its input-file/input-directory, but the context here is that the 
item is actually a set of database-actions which were valid when the ppss run 
started, but due to earlier processed ITEMS is no longer valid (and this can be 
detected at run time by "command").

Similarly, the ability to get ppss to make another pass through it's input-file 
(or input-directory) to process "unprocessed" (delayed) items is due to the 
ITEMS being database activities that would "clash" (i.e. cause temporary 
failures) if they were concurrent but which would succeed if run at a later 
time. In this situation it is not predictable in advance (i.e. when creating 
the input-file or the input-directory contents) which items can safely be 
concurrent, but it can be detected automatically by "command" at run-time. I 
also know that I could myself find FAILED ITEMs in job_log and submit retries, 
but once again I'd like to have ppss do it for the parallellism specifically to 
avoid "false failures" that can result from ITEMs being concurrent at the wrong 
moment that would succeed if delayed for a subsequent pass. A subsequent-pass 
would only happen in ppss if ppss reached the end of its input-file (or 
input-directory) and there was at least one delayed-job.

Original issue reported on code.google.com by oreilly....@gmail.com on 6 Nov 2011 at 4:58

GoogleCodeExporter commented 9 years ago
I understand what you want. I don't think that it is the job of PPSS to realize 
what you want. You may have outgrown PPSS. 

The proper way to solve this is to create a wrapper script that is called with 
-c. This script writes failed/suspended items to a new list or file. If you run 
PPSS in DAEMON mode or through cron, this new list or file can be picket up at 
the next run.

Why would this not suit your needs?

Original comment by Louwrentius on 21 Dec 2011 at 12:24

GoogleCodeExporter commented 9 years ago
The idea that failed items are retried is interesting. An extra option allows 
you to specify a retry and delay count.  However, I have to think this through 
as it may take some substantial work.

Original comment by Louwrentius on 21 Dec 2011 at 12:28