Autosys retry job if main job fails - autosys

I have my spring boot application hosted on PCF. I have two autosys job defined:
Main job: Hits the post request, but there is a database condition check, in case it fails the post request will return HTTP Status 425. In case I am getting anything apart from HTTP Status 200, the retry job should run.
Retry job: Retry job is also hitting the post request iff the main job fails (here fail meaning not getting HTTP status response to be 200).
However, even if the HTTP status fro the main job is not 400, still the autosys job run is showing success. How can I get the FAILURE status for main job in case of anything apart from HTTP Status 200. Please help. If more details are required let me know.

Related

dp:url-open's timeout value is getting ignored in datapower

I am providing a timeout of one second , however when the URL is down it is taking 120+ seconds for the response to come. Is there some variable or something that overrides the timeout in do:url-open ?
Update: I was calling the dp:url-open on request-transformation as well as on response-transformation. So the overriden timeout is 60 sec, adding both side it was becoming 120 sec.
Here's how I am calling this (I am storing the time before and after dp:url-open calls, and then returning them in the response):
Case 1: When the url is reachable I am getting a result like:
Case 2: When url is not reachable:
Update: FIXED: It seems the port that I was using was getting timed-out in the firewall first there it used to spend 1 minute. I was earlier trying to hit an application running on port 8077, later I changed that to 8088, And I started seeing the same timeout that I was passing.
The do:url-open() timeout only affects the operation done in the script but not the service itself. It depends on how you have built the solution but the time-out from the do:url-open() should be honored.
You can check this by setting logs to debug and adding a <xsl:message>Before url-open</xsl:message> and one after to see in the log if it is your url-open call or teh service that waits 120+ sec.
If it is the url-open you have most likely some error in the script and if it is the service that halts the response you need to return from the script (or throw an error depending on your needs) to halt the service.
You can set the time-out for the service itself or set a time-out in the User Agent for the specific URL you are calling as well.
Please note that the time-out will terminate the service after that time if you set it on service level so 1 sec. would not be recommended!

Is there any way to pass the error text of a failed Airflow task into another task?

I have a DAG defined that contains a number of tasks, the last of which is only run if any of the previous tasks fail. This task simply posts to a Slack channel that the DAG run experienced errors.
What I would really like is if the message sent to the Slack channel contained the actual error that is logged in the task logs, to provide immediate context to the error and perhaps save Ops from having to dig through the logs.
Is this at all possible?

How to make async requests using HTTPoison?

Background
We have an app that deals with a considerable amount of requests per second. This app needs to notify an external service, by making a GET call via HTTPS to one of our servers.
Objective
The objective here is to use HTTPoison to make async GET requests. I don't really care about the response of the requests, all I care is to know if they failed or not, so I can write any possible errors into a logger.
If it succeeds I don't want to do anything.
Research
I have checked the official documentation for HTTPoison and I see that they support async requests:
https://hexdocs.pm/httpoison/readme.html#usage
However, I have 2 issues with this approach:
They use flush to show the request was completed. I can't loggin into the app and manually flush to see how the requests are going, that would be insane.
They don't show any notifications mechanism for when we get the responses or errors.
So, I have a simple question:
How do I get asynchronously notified that my request failed or succeeded?
I assume that the default HTTPoison.get is synchronous, as shown in the documentation.
This could be achieved by spawning a new process per-request. Consider something like:
notify = fn response ->
# Any handling logic - write do DB? Send a message to another process?
# Here, I'll just print the result
IO.inspect(response)
end
spawn(fn ->
resp = HTTPoison.get("http://google.com")
notify.(resp)
end) # spawn will not block, so it will attempt to execute next spawn straig away
spawn(fn ->
resp = HTTPoison.get("http://yahoo.com")
notify.(resp)
end) # This will be executed immediately after previoius `spawn`
Please take a look at the documentation of spawn/1 I've pointed out here.
Hope that helps!

netflix conductor - http type task - should not start with workflow - to achieve retry

I have created a task with retry of 5 times.And created a workflow using the task of http type(my rest url api endpoint) for input parameters.
But the moment I run the workflow - it is hitting the rest api.
where actually I want to run the task by worker - inside my rest service to call another upstream service.
what I want - the rest url(url-2) is the Upstream of another url(url-1). when my application call url-1, in code I will use conductor task to hit url-2, and based on status, or down, I will fail the status- and it will retry.

What does the START_MANUAL status code mean in Oozie?

I've got a java action that's been suspended for 5 days with this status, and I don't know what oozie wants me to do. Any ideas?
It means that there was an error. And possibly multiple retries if you have retries configured. When retries are configured, after the first error the job goes to START_RETRY and Oozie retries automatically.
After the maximum number of retries is reached, the flow goes to state START_MANUAL. In that state, Oozie assumes that you will intervene and either fix the error and resume the job or kill the job.
There is a little more info in the documentation: http://oozie.apache.org/docs/3.3.2/WorkflowFunctionalSpec.html#a18_User-Retry_for_Workflow_Actions_since_Oozie_3.1

Resources