You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Suhas Vasu (JIRA)" <ji...@apache.org> on 2014/05/28 14:50:02 UTC

[jira] [Updated] (OOZIE-1859) The API getCoordJobInfo behaves unexpectedly if the Oozie DB is purged

     [ https://issues.apache.org/jira/browse/OOZIE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Suhas Vasu updated OOZIE-1859:
------------------------------

    Description: 
The API 'getCoordJobInfo' returns the actions for a given coordinator from a given start action number and specified length. But if the DB tables are purged, it returns unexpected values.

The function sets the start action number based on the the least action number of the coordinator available in the table. Assuming we have a external script, that purges the DB tables periodically to maintain good response time for queries, it would delete earlier actions of a long running coordinator. 
Ex: Say a hourly job is running for a year now, it would have action number around 10000, to maintain the response times we may purge the coord action table till around action number 5000.
In such cases, the start action number provided is not set as passed to the API, instead it is set based on the starting action number available for that coordinator in the coord action table in the DB..

So it would be ideal, if we figure out the least available action number for a coordinator available in the DB table and adjust the start action number accordingly. This approach shouldn't affect the existing functionality of the API.

  was:
The API 'getCoordJobInfo' returns the actions for a given coordinator from a given start action number and specified length. But if the DB tables are purged, it returns unexpected values.

The function sets the start action number based on the the least action number of the coordinator available in the table. So if the DB is purged, the start action number provided is not set accordingly.

So it would be ideal, if we figure out the least available action number for a coordinator available in the DB table and adjust the start action number accordingly. This approach shouldn't affect the existing functionality of the API.


> The API getCoordJobInfo behaves unexpectedly if the Oozie DB is purged
> ----------------------------------------------------------------------
>
>                 Key: OOZIE-1859
>                 URL: https://issues.apache.org/jira/browse/OOZIE-1859
>             Project: Oozie
>          Issue Type: Improvement
>            Reporter: Suhas Vasu
>
> The API 'getCoordJobInfo' returns the actions for a given coordinator from a given start action number and specified length. But if the DB tables are purged, it returns unexpected values.
> The function sets the start action number based on the the least action number of the coordinator available in the table. Assuming we have a external script, that purges the DB tables periodically to maintain good response time for queries, it would delete earlier actions of a long running coordinator. 
> Ex: Say a hourly job is running for a year now, it would have action number around 10000, to maintain the response times we may purge the coord action table till around action number 5000.
> In such cases, the start action number provided is not set as passed to the API, instead it is set based on the starting action number available for that coordinator in the coord action table in the DB..
> So it would be ideal, if we figure out the least available action number for a coordinator available in the DB table and adjust the start action number accordingly. This approach shouldn't affect the existing functionality of the API.



--
This message was sent by Atlassian JIRA
(v6.2#6252)