I have an informatica worklow which I need it to be restarted in case of error. In case it fails 2 o 3 times, it should send a notification. Can you advise how to do this?
Related
The deploy to some of the servers takes extremely long. Where it normally takes like 30 seconds to download the artifact on some servers it can take over 8 minutes, sometimes the deploy even fails if it takes too long. This behavior is consistent for the same server and it didn't changed for atleast the past 2 weeks.
Internet connectivity is good and I see 1gbit up and down with a speedtest on these servers. We use west europe as region and I can confirm this by looking at the urls in the log.
In the log I see these kind of messages:
2022-04-19T08:07:15.8187615Z ArtifactHttpRetryMessageHandler.SendAsync: https://vsblobprodsu6weu.vsblob.visualstudio.com/someguid/_apis/dedup/urls attempt 1/6 failed with TimeoutException: 'The HTTP request timed out after 00:01:40.'
What can cause this to happen?
I have a server that runs Postgresql. in the logs I am seeing this message for my resque based 'worker' box, multiple times a minute. Some minutes there isn't a message, others could be 10 times.
2016-01-12 13:40:36 EST:1.1.8.2(33899):[16141]: LOG: could not receive data from client: Connection reset by peer
Now when i go into the 1.1.8.2 box to look at netstat -ntp i don't see a port 33899, and most of them are at least in the 40xxx range by now. That may be conjecture but I'm at a loss to find out why a Redis/Resque/Puma Rails stack would be printing out these messages, let alone what that means even if i get to the bottom of it.
Will I gain memory back if they are closed 'normally'?
Is this a thing to be wary of?
How does one debug OLD ports that are open when the db box and the worker box both don't display the ports any more?
This message is probably due to the resque worker task not closing the database connection before it exits. It's not a huge problem, but presumably Postgres is doing a little extra work to clean it up, and it makes a mess of your log file...
One solution is to add a hook to your resque worker's task file (the same file that contains the self.perform definition):
def self.after_perform(*args)
ActiveRecord::Base.connection.disconnect!
end
I am using the blueprints graph api for orient against a 2 node cluster running orient 1.7.10. When ingesting simple parent child data I intermittently get the following error on commit -
Warning: caught I/O errors from not connected (local socket=?), trying to reconnect (error: java.io.IOException: Channel is closed)
The connection is then reestablished:
Connection re-acquired transparently after 31ms and 1 retries: no errors will be thrown at application level.
This occurs mid way through the commit (100 vertices and edges) with the result that the server thinks it has sent the response but the client hangs forever.
Is there a way to catch this at the application level and e.g. rollback?
I would be very grateful for any help?
As far as i know a very similar issue was fixed some time ago: https://github.com/orientechnologies/orientdb/issues/2930
one thing to be aware is that autostart transaction of the graph, if is enabled (and it is by default) you don't need to do begin, but just commit, if you do begin the transaction will be committed at shutdown and in that case can create that problem.
another suggestion is migrate to 2.0-* releases that have important improvement also in that side, especially if you are in development phase, the 2.0 final is going to be released very soon and will be the one with major focus in the next months.
bye
we have a job that runs several times a day making incremental backups.
We have added a step 'Send email on Job failure' that uses T-SQL to send an email to the admins team if the first step (Incremental backup) has failed.
Unfortunately we must have configured the Advanced options in the second step incorrectly, as we are getting an email even when the first step has succeeded.
The email is being sent successfully by the second step.
We have configured the options for the first step as follows:
On success quit reporting success
On failure goto Step 2 - Send email
We have configured the options for the second step as below:
On success quit reporting success
On failure goto Step 2 - Send email
Now, when the task, step 1 succeeds, we don't expect to receive an email. When step 1 fails we expect an email.
So what are we doing wrong?
Not sure if what you have written is truly the step, if it is then this is the reason you are always getting an email.
Step 1 = Fail => Go To step 2. Send Email
Step 1 = Success => Go To step 2. Send Email
You should have the Notifications "tab" configured to sent an email "When Job Fails"
I've developed a pooling logic in bpel process on the WSO2 BPS 3.0.0 connected to a Postgresql 9 DB.
It looks like this:
<bpel:repeatUntil name="RepeatUntilIncidentCompleted">
<bpel:sequence name="CheckIncidentStatus">
<bpel:wait name="Wait">
<bpel:for expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA['PT1M']]></bpel:for>
</bpel:wait>
<!-- invoke a service, copy status to a vStatus variable -->
</bpel:sequence>
<bpel:condition expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[$vStatus=36]]></bpel:condition>
I created a process instance and this loop worked fine.
Later I restarted the WSO2 BPS server. In the moment of the restart the process instance was in the loop, but after restart the loop wasn't running anymore. The process is marked as active in the carbon console.
I've added the in-memory=false property in the deploy.xml but it didn't help.
I could have missed some configuration but there also can be a persistence problem with such a loop (probably in the Apache ODE).
Does anyone know a solution to this problem? Thx in advance.
I've discovered that:
1. All sleep operations that you put in a wso2 bpel process are represented in the ode_job table. The attribute ts contains the time of wake up.
2. After restart of the bps server all delayed sleep operations aren't continued (a sleep operation is delayed when wake up time < current time - offset ).
3. After restart of the bps server all non-delayed sleep operations that are continued properly.
Now let's say that:
- You have a bpel process instance that waits in a wait operation. The wake up time is X.
- You stop the bps server, and start it again after X.
Because of 2. the process instance won't continue after restart. This includes the loop I've described earlier.
My workaround to the problem:
Everytime the wso2 bps server is restarted I execute a sql script on the database that updates the wake up attribute of the sleep operations (the ts column in the ode_job table). The wake up times are set to some near future.
I don't know if you can change the 2. / 3. behaviour by configuration. I couldn't find any documentation about it. Some code analasis is needed here. To make things worse, wso2 uses it's own apache ode branch, so you can't just update the apache ode library.
I suspect that there can be two reasons for the behaviour described in 2.:
- delayed sleep operations are droped
- delayed sleep operations are executed right after restart, but the process definitions aren't loaded yet.