I have a distributed Openwhisk setup, and when I execute a large number of functions simultaneously like this
wsk -i action invoke test -r -b
at some point instead of getting the actual result, I start getting the following message:
ok: invoked /_/test, but the request has not yet finished, with id
Any idea how I could force Openwhisk execute the function and still return the result regardless how long the invocation actually takes? Is there maybe some playbook variable responsible for timeout?
You can execute a function in non-blocking mode. In this case, you will get the activation ID immediately and function execution will happen in the background. You can then check/track the status of function execution with the activation ID.
Remove the "-b" option from the command.
Also, a function execution timeout is configurable (default 60s), if function execution requires more time to execute, you can define it while creating the function.
For per function limit you can specify below setting when creating the function.
-t, --timeout LIMIT the timeout LIMIT in milliseconds after which the action is terminated (default 60000)
Related
I am using global window with repeated forever after processing time trigger to process streaming data from pub-sub as below :
PCollection<KV<String,SMMessage>> perMSISDNLatestEvents = messages
.apply("Apply global window",Window.<SMMessage>into(new GlobalWindows())
.triggering(Repeatedly.forever(AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardMinutes(1))))
.discardingFiredPanes())
.apply("Convert into kv of msisdn and SM message", ParDo.of(new SmartcareMessagetoKVFn()))
.apply("Get per MSISDN latest event",Latest.perKey()).apply("Write into Redis", ParDo.of(new WriteRedisFn()));
Is there a way to make repeatedly forever apache beam trigger to only execute after the previous execution is completed ? The reason for my question is because the next trigger processing will need to read data from redis, written by the previous trigger execution.
Thank You
So the trigger here would fire at the interval you provided. The trigger is not aware of any downstream processing so it's unable to depend on such steps of your pipeline.
Instead of depending on the trigger for consistency here, you could add a barrier (a DoFn) that exists before the Write step and only gives up execution after you see the previous data in Redis.
You could try and explicitly declare a global window trigger, as the example below:
Trigger subtrigger = AfterProcessingTime.pastFirstElementInPane();
Trigger maintrigger = Repeatedly.forever(subtrigger);
I think that triggers would help you on your case, since it will allow you to create event times, which will run when you or your code trigger them, so you would only run repeatedly forever when a trigger finishes first.
I found this documentation which might guide you on the triggers you are trying to create.
I wanted to run a script if a split brain is detected. In the documentation, it is mentioned that we can do that by providing the path of the script like
resource <resource>
handlers {
split-brain <handler>;
...
}
But, below that, for the after-sb-0pri configuration, it is mentioned that
disconnect: Do not recover automatically, simply invoke the
split-brain handler script (if configured), drop the connection and
continue in disconnected mode.
So, my question is that, will the configured script be run only when after-sb-0pri is set to disconnect, or will that run for any set value
Document Link: https://linbit.com/drbd-user-guide/users-guide-drbd-8-4/#s-configure-split-brain-behavior
DRBD should invoke the split-brain handler whenever a split-brain is detected. I.E. Anything that would log a Split-Brain detected ... in the system/kernel logs. The documentation attempts to explain this at the beginning of chapter 5.17.1 with:
DRBD invokes the split-brain handler, if configured, at any time split
brain is detected.
Additionally, disconnect is the default value for after-sb-0pri. So, even if not explicitly set that will still be the behavior.
I use exec() function on cypress but I get timeout error sometimes even if it works properly.
Is there any possibility ignore this timeout error?
I do not want to see this error. I want to see always pass/true in any case.
You can look into failOnNonZeroExit options flag. It determines whether to fail if the command exits with a non-zero code.
cy.exec('some commands', { failOnNonZeroExit: false })
Or, You can also pass a timeout options object with cy.exec(), something like:
cy.exec('some commands', { timeout: 10000 }) //timeout for 10 seconds
So, in my collection I have about ten requests, with the last two being:
/Wait 10 seconds
/Check Complete
The first makes a call to the postman's echo (delay by 10 seconds) and the second is the call to my system to check for the status complete. Now, if status is unavailable I wait another 10s:
postman.setNextRequest("Wait 10 seconds");
The complete status on my system can appear in a minute or so. Now, as one can see - it is an infinite loop if something goes wrong with the system and status is never complete. Is there a way in postman/newman test to fail a test if it has been going for more than 2 minutes, for example.
Additionally, this will be executed in jenkins with command line, so I am not really looking into postman settings or delays between requests in the runner.
you may have a look to newman options here : https://www.npmjs.com/package/newman#newman-run-collection-file-source-options. The interesting option is
--timeout-request : it will surely fulfill your need.
In Postman itself, you may test the responseTime. I recall that there is a snippet, on the right part, which looks like this:
tests["Response time is less than 200ms"] = responseTime < 200;
and which could help you as the test fails if response does not occur within the requested time.
Alexandre
If you are going to be using Jenkins pipeline you can use the timeout step to cause long running jobs to result in failure, here's on for 2 mins.
timeout(120) {
node {
sh 'newman command'
}
}
Check out the "Pipeline Syntax" editor in Jenkins to generated your code block and look for other useful functions.
In my application I want to terminate the exec! command of my SSH connection after a specified amount of time.
I found the :timeout for the Net::SSH.start command but following the documentation this is only for the initial connection. Is there something equivalent for the exec command?
My first guess would be not using exec! as this will wait until the command is finished but using exec and surround the call with a loop that checks the execution status with every iteration and fails after the given amount of time.
Something like this, if I understood the documentation correctly:
server = NET::SSH.start(...)
server.exec("some command")
start_time = Time.now
terminate_calculation = false
trap("TIME") { terminate_calculation = ((Time.now - start_time) > 60) }
ssh.loop(0.1) { not terminate_calculation }
However this seems dirty to me. I expect something like server.exec("some command" { :timeout=>60}). Maybe there is some built in function for achieving this functionality?
I am not sure if this would actually work in a SSH context but Ruby itself has a timeout method:
server = NET::SSH.start ...
timeout 60 do
server.exec! "some command"
end
This would raise Timeout::Error after 60 seconds. Check out the docs.
I don't think there's a native way to do it in net/ssh. See the code, there's no additional parameter for that option.
One way would be to handle timeouts in the command you call - see this answer on Unix & Linux SE.
I think your way is better, as you don't introduce external dependencies in the systems you connect to.
Another solution is to set ConnectTimeout option in OpenSSH configuration files (~/.ssh/config, /etc/ssh_config, ...)
Check more info in
https://github.com/net-ssh/net-ssh/blob/master/lib/net/ssh/config.rb
what I did is have a thread that's doing the event handling. Then I loop for a defined number of seconds until channel closed.If after these seconds pass, the channel is still open, then close it and continue execution.