what is the difference between them? from docs, it says "currently running" vs "has been started"?
For example, two thread, one is main, the other is called A.
If currently, main is running, and A started once(). Will A.isRunning() return false? will A.isStarted() return ture?
what if A never starts?
The docs could be clearer. From reading the source code I can see that it enters Started state once, when the function is first run, and that flag doesn't get cleared (even if task is cancelled). So A.isStarted() should return true. isRunning() however is the actual current state, which depends on current progress (eg. !isFinished()), or is false for example if it was paused or cancelled (or caught an exception).
Related
My painful hunt for this feature is fully described in disgustingly log question: Several last offsets aren't getting commited with reactive kafka and it shows my multiple attemps with different failures.
How would one subscribe to ReactiveKafkaConsumerTemplate<String, String>, which will process the records in synchronous way (for simplicity), and will ack/commit every 2s AND upon manual cancellation of stream? Ie. it works, ack/commits every 2s. Then via rest/jmx/whatever comes signal, the stream terminates and ack/commits the last processed kafka record.
After a lot of attempts I was able to come up with following solution. It seems to work, but it's kinda ugly, because it's very "white-box" where outer flow highly depends on stuff happening inside of other methods. Please criticise and suggest improvements. Thanks.
kafkaReceiver.receive()
.flatMapSequential(receivedKafkaRecord -> processKafkaRecord(receivedKafkaRecord), 16)
.takeWhile(e-> !stopped)
.sample(configuration.getKafkaConfiguration().getCommitInterval())
.concatMap(offset -> {
log.debug("ack/commit offset {}", offset.offset());
offset.acknowledge();
return offset.commit();
})
.doOnTerminate(()-> log.info("stopped."));
What didn't work:
A) you cannot use Disposable.dispose, since that would break the stream and your latest processed record won't be committed.
B) you cannot put take on top of stream, as that would cancel the stream and you won't be able to commit either.
C) not sure how I'd be able to intercorporate usage of errors here.
Because of what didn't work stream termination is triggered by boolean field named stopped, which can be set anyhow.
Flow explained:
flatMapSequential — because of inner parallelism and necessity to commit N only if all N-1 was processed.
processKafkaRecord returns Mono<ReceiverOffset>, ie. the offset of processed record to have something to ack/commit. When stopped the method will skip processing and return Mono.empty
take will stop stream if stopped, this has to be put here becaue of possibility of whole sample interval consisting only from "empties"
rest is simple: sample by given interval, commit in order. If sample does return empty record, commit is skipped. Finally we log that stream is cancelled.
If anyone know how to improve, please criticise.
I'm stuck on something in my Robot Framework project. When I hit a button from the 1st page after the login is done, another tab is opened, however, sometimes, the new window is not loaded and the code (robotframework) keep waiting for an answer.
To avoid getting an error when this situation happens, I want to solve it while the code still running, I want to know if there is any keyword that applies an action in case something is not done within a given lead time. In my case it would be to close the new window and repeat the previous step (hit the button from the first page again), therefore, it would be 2 actions in case the actions fails (lead time).
I have tried to use the keyword Run Keyword and Return Status, in my case the status would be false, however, since my code is kept waiting for an answer, the status is always True, therefore, it does not work for me.
I have read that there is a keyword named Run Keyword If Timeout Occurred however, it can be only used on Teardown`, therefore, I also don't know if it can applied.
I see you are trying to compare Boolean and String.
it's should be boolean and boolean run Keyword if ${status}==False.
I can't find a release method in the docs. Is it hiding somewhere where I can't see?
Any help would be greatly appreciated.
Thanks!
You can decrement the reference count of an event using clReleaseEvent:
Decrements the event reference count. The event object is deleted once the reference count becomes zero, the specific command identified by this event has completed (or terminated) and there are no commands in the command-queues of a context that require a wait for this event to complete.
Note however that:
Developers should be careful when releasing their last reference count on events created by clCreateUserEvent that have not yet been set to status of CL_COMPLETE or an error. [...]
User events are created with an initial reference count of 1, as per the OpenCL specification (§5.9 Event Objects):
The OpenCL commands that return an event perform an implicit retain.
Therefore if you haven't performed any additional retain on your user event, passing it to clReleaseEvent should delete it immediately. You must take care that your event was marked as complete, otherwise your application may end up in a deadlock.
I have a doubt about Ada, and in particular about the select statement when used in conjunction with a protected entry. Let's consider the following code fragment:
select
Protected_Object.Some_Entry;
else
DoSomethingElse;
end select;
My question is simple: when the select statement is reached, what happens? In particular, what I want to know is: does the else branch get chosen only if Some_Entry's guard is closed or does it get chosen even if the guard is opened but the entry is "occupied" (ie: there's already a call to Some_Entry executing) and thus cannot be called immediately??
I believe that the else branch is chosen only if the entry's guard is closed (i.e. the barrier condition is false). The sequence of events for a protected entry call is given by RM 9.5.3(8):
A new protected action is started on the object.
The named entry is checked to see if it is open (i.e. the barrier condition is true); if open, the entry call is said to be selected immediately, and then the entry body is executed.
Starting a protected action may involve a short delay if another task is performing a protected action on the same object (9.5.1(4)). However, the intent is that this delay is always very short. If a protected subprogram or entry does anything that could block the program, this is considered an error (9.5.1(8-18)). Thus, waiting until another task releases a protected object is supposed to be a very short wait if at all; on a multi-processor system, it's perfectly acceptable to implement this wait by spinning (essentially while Protected_Object_Is_In_Use(Obj) loop null; end loop;) as opposed to waiting on a queue.
Thus, my reading of 9.5.3(8) is that the definition of "selected immediately" does not take into account the short wait needed if another task is engaged in a protected action on the object. If the task has to wait, it does so. If, once it is able to grab the object, it finds that the barrier is true, then the entry is "selected immediately". This may not quite fit our idea of what the English word "immediately" means, but it's how the term is defined.
Thus, for a conditional entry call, RM 9.7.3 says that the entry call is cancelled (and the else branch executed) if it is not selected immediately. Using the definition in 9.5.3(8), this means that the else branch is executed only if the barrier condition is false (after the task succeeds in grabbing the protected object).
The 'else' branch is chosen if Some_Entry is not immediately accessible (either because there is already another task accessing the protected object, or because the guard prevents calling the entry in the first place.
The goal of the 'else' branch is basically that your task does not stay blocked and thus might miss a timeout or an action to execute on a regular schedule. So when you use 'else', the select statement cannot be blocking (unless of course the entry itself, once called, takes forever).
Edit: As demonstrated below by #simonwright, this answer is incorrect: the 'else' branch is taken when the guard is False, otherwise the task will block on the protected object's entry. By design, such entries should perform their work in a very limited amount of time.
I have read the man pages.
All I understood from this link http://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr2/zid-7281.htm is that
A successful call to execve does not have a return value because the new process image overlays the calling process image
I am not very clear as to why this will happen ? And if the new process overlays the calling process, why does it return on failure only and not on success ?
Because if it fails to do what it is trying to do, i.e. replace the process with the new one, then it makes sense to return, to inform the caller that it failed.
If it succeeds, then the code that called execve() is no longer present, it has been replaced by the successful execution of that function, so obviously it cannot do anything any more. Returning is such a thing.