As I understand escalation event is used to inform parent process. If escalation event is interrupting, it means that regular flow will be ignored and a new flow will be handled. But it is similar to error event. What is the difference?
You are right, escalation events are used to communicate from a subprocess to a parent process. Unlike an error, an escalation event is, by default, non critical and execution continues at the location of throwing.
The difference in notation is that
Error events are always interrupting (as the name suggests), either as an Event Sub-process start event or a Boundary event of a Sub-process.
Escalation events are by default non-interrupting but they can also be modelled as interrupting events. They can, just like Error events be Event Sub-process start events or Boundary events.
The more important semantic difference is that Escalation events gives you a bit more flexibility in modeling a business activity. Not everything that goes wrong during a process is an error. Sometimes, things just don't go quickly enough or there is a non-business critical piece of information that the parent process should know about.
[][https://www.omg.org/spec/BPMN/2.0/]
Related
Say I am doing an Ask() on actor with some timeout, if the ask timesout, is there a way to get the underlying actor to stop processing things? For example, I don't want the main thread / caller to continue and this actor is still processing the timed out request
Short answer is no, you cannot do it.
Long answer is it depends.
You could move actor's work to another execution context via a Future for example. This will allow your actor react on other messages but that Future that actor has started cannot be cancelled if it was picked up by an execution context and not hanging in the queue of the execution context.
You could write some smart Future wrapper that would check if future was cancelled before starting the work. But if processing has started, the only thing you can do is calling interrupt on the thread executing the future (meaning that you need to capture this thread somehow) and hopping that the work will hit Object.wait or Thread.sleep methods, ie the only places when the interrupt exception can be received. But there is no guarantee of this ever happening.
No you can't. The only thing you can do to an actor is send a message to it. You can't 'get' the actor in any kind of other kind of way to interrupt it. And since, under normal circumstances, messages are processed in order any subsequent "stop processing" message will only be processed after the first message was already completed.
I think the solution to your problem will depend a bit on why you suspect the actor may "time out" in responding.
For example, where you might expect the Actor may sometimes have a backlog of messages, I think the best solution may be to include the timeout as part of the message. In your receiveMessage handler you can check this "request expiry" time before doing actual work, and if the timeout has already passed, just discard the message.
I don't understand part of the latest Windows threadpool API. I need help with that.
From the documentation, the recipe to use it for I/O (in my case, for SOCKET) can be summarized as follows:
Call CreateThreadpoolIo.
Call StartThreadpoolIo. You can find this warning there:
You must call this function before initiating each asynchronous I/O operation on the file handle bound to the I/O completion object. Failure to do so will cause the thread pool to ignore an I/O operation when it completes and will cause memory corruption.
Call the operation on the file handle (e.g., WSARecvFrom). If it fails, call CancelThreadpoolIo. Otherwise, process the result when it is available. WSARecvFrom, when used asynchronously, asks for a WSAOVERLAPPED (that you have to create beforehand) but not for any information that links it to the previous call to StartThreadpoolIo. CancelThreadpoolIo only asks for the PTP_IO, but not for any additional information to derive a specific asynchronous operation.
Repeat steps 2 and 3.
Call CloseThreadpoolIo to finish. You can find this warning there:
It may be necessary to cancel threadpool I/O notifications to prevent memory leaks. For more information, see CancelThreadpoolIo.
I usually need it for UDP, so I strive to have several reception operations queued (asynchronous WSARecvFrom operations started) at any given time. That way I don't have to rush to start another reception operation at the beginning of the callback function nor synchronize access to the reception buffers (I can have a pool of them, each one able to contain a datagram, and reissue the reception operation when I finish processing each message; in the interim, other queued operations will keep the receiver busy). Datagrams are independent and self contained. I'm aware that this approach may not be valid for TCP.
StartThreadpoolIo/CancelThreadpoolIo seem to me the source of the problem: StartThreadpoolIo and WSARecvFrom are not directly bound (they don't share any arguments). So:
How can the framework know which operation to cancel when you call CancelThreadpoolIo? How does it cancel just the operation that failed and not any of the pending ones?
You can say, "don't call StartThreadpoolIo concurrently". I can live without several concurrent WSARecvFrom's, but I can't live without concurrent WSARecvFrom and WSASendTo. So I think being unable to have several asynchronous operations at the same time can't be the way the API was designed.
You can say, "call StartThreadpoolIo only once, that will suffice to register the callback; it is an on/off process". But the documentation says:
You must call this function before initiating each asynchronous I/O operation on the file handle...
You can say, "it cancels the operation started by the same thread that just called StartThreadpoolIo". But then the advice of calling CancelThreadpoolIo in the context of calling CloseThreadpoolIo doesn't make sense (I will call CloseThreadpoolIo from the thread that triggers stopping, which will be completely independent from the threads issuing the asynchronous operations; and a single call to CancelThreadpoolIo may not be enough to cancel several operations). Being unable to trigger cancellation from a different thread is a serious limitation, anyway. I'm aware of the existence of CreateThreadpoolCleanupGroup, but my question is more fundamental. I want to understand how this API can be fundamentally right and useful.
You can say "call CreateThreadpoolIo several times, so that you have independent PTP_IO's to work with". It doesn't work. When I call CreateThreadpoolIo a second time, nullptr is returned.
Am I wrong, or is this API awkward? Normally, other asynchronous APIs work with one of these patterns:
Create an operation and receive a handle => call methods passing the handle.
Create a reusable handle => call methods (including starting operations) passing the handle.
The latest Windows threadpool API, in which the handle seems to be implicit, or there are several handles for the same operation (TP_IO, WSAOVERLAPPED, StartThreadpoolIo) and they aren't all explicitly linked together, uses neither of them.
Thank you very much for your help.
How can the framework know which operation to cancel when you call CancelThreadpoolIo? How does it cancel just the operation that failed
and not any of the pending ones?
CancelThreadpoolIo() doesn't cancel IO. It is reciprocal to StartThreadpoolIo(). StartThreadpoolIo() prepares threadpool to accept a completion. If threadpool doesn't expect a completion, it won't wait for it, thus you may miss it. If threadpool expects a completion but completion doesn't happen, threadpool may waste resources.
CancelThreadpoolIo() undoes whatever StartThreadpoolIo() did.
An asynchronous call to ReadDirectoryChangesW() can be cancelled by the CancelIo() function. However, by the time CancelIo() has been called, the notification buffer associated with ReadDirectoryChangesW() may be half filled in. The question is, what happens with those notifications? Should they be processed in a normal way?
More specifically, I issued an overlapped ReadDirectoryChangesW() command with a completion routine, and than cancelled it by means of CancelIo(). When my completion routine is called with an ERROR_OPERATION_ABORTED error, should I still check the notification buffer for possible notifications?
Clarification:
My File System Listener component successfully serves for my company already more than ten years. Now I'm going to modify the component in order to implement a more sophisticated monitoring policy. With this policy, cancelling a particular ReadDirectoryChangesW() request doesn't mean cancelling of monitoring, and I do not want to miss even a single notification.
OK, I found experimentally that the second parameter of completion routine (dwNumberOfBytesTransfered) in the case of ReadDirecoryChangesW() function contains number of bytes written to notification buffer. Unfortunately, I didn't find a clear confirmation of that in documentation.
However, this hypothesis seems reasonable, and if it is always true, I can conclude about presence of notifications by checking of that parameter regardless of the completion routine's first parameter (dwErrorCode). This solves the problem.
Windows 8, x64.
Using overlapped Windows sockets Api with IOCP.
Noticed an unexpected behavior with sockets:
For example, a call to DisconnectEx returns an error WSAENOTCONN but later I receive an event in GetQueuedCompletionStatusEx for exactly this disconnect (like it was still scheduled regardless of returned error).
Same happens with AcceptEx (with different error returned, e.g. WSAEINVAL).
I was expecting the IOCP event to be scheduled only for pending operations (returned error code WSA_IO_PENDING), but not other errors.
EDIT: My question is: can IOCP events be scheduled by the system even if calls to DisconnectEx/AcceptEx return an error (WSAGetLastError) that is not WSA_IO_PENDING?
Thank you!
IOCPs tend to flood you with statuses at seemingly odd times, including after you thought the handle was closed... The solution I used for this was to do a PostQueuedCompletionStatus() with a custom OVERLAPPED parameter to indicate "closed for real now" after I had closed the handle. Then any queued system statuses would be processed, and when I got the custom OVERLAPPED I knew I could free all my internal buffers related to the handle.
The answer for the above question is no. The problem I had is I messed up scheduling several IOCP events on the same overlapped structure which resulted in this strange behavior.
For another question, I'm running into a misconception that seems to arise here at SO occasionally. Some questioners seem to think that Triggers are to Databases as Events are to OOP.
Does anyone have a good analogy to explain why this is a flawed comparison, and the consequences of misapplying it?
EDIT:
Bill K. has hit it correctly, but maybe doesn't see the importance of the critical differeence between the event and the callback function that strikes me, anyway. Triggers actually cause code to execute every time the event occurs; callbacks only occur whenever one has been registered for an event (which is not true for the vast majority of events); and even then, in most cases the callback's first action is to deregister itself (or at least the callback contains a qualifcation exit so it only executes once.)
If you write a trigger, it will unfailingly execute every time the event occurs, because there's no way to register or deregister to code segment.
Triggers are a way to interpose repeating logic synchronously into the thread of execution (i.e. synchronicity). Events are a means to defer logic until later (i.e. implement asynchronicity).
There are exceptions and mitigations in both cases, but the basic patterns of triggers and callbacks are mostly opposite in intention and implementation. Often the distinction doesn't seem to have fully sunk in. (IMHO, YMMV). :D
They're not the same thing, but they're not unrelated.
In both cases, the mechanism can be described approximately as follows:
Some block of code declares "interest" for changes in state.
Your application affects some change.
The system runs the block of code in response to the change.
Perhaps a database trigger is more like a callback function that has registered interest in a specific event.
Here's an analogy: the event is a rubber ball that you throw. The trigger is a dog that chases after a thrown ball.
If there's some other difference that you have in mind that makes it "dangerous" (note: OP has edited this choice of word out of the question) to compare triggers and events, you can describe what you mean.
Triggers are a way to interpose
repeating logic synchronously into the
thread of execution (i.e.
synchronicity). Events are a means to
defer logic until later (i.e.
implement asynchronicity).
Okay, I see what you mean more clearly. But I think it's in some ways subject to the implementation. I wouldn't assume an event handler has to deregister itself; it depends on the system you're using. A UNIX signal handler, for example, has to prevent itself from catching a new signal while it's already handling one. But a Java servlet inside a Tomcat container should be thread-safe because it may be called concurrently by multiple threads. They're both event handlers, of different kinds.
Event handlers may be synchronous or asynchronous. Can a handler in a publish/subscribe system read messages that were posted recently, but prior to the handler registering its interest? Or only messages posted concurrently?
There's another important reason to treat triggers as different from event handlers: I frequently recommend against doing anything in a trigger that affects state outside the database.
For example, sending an email, writing to a file, posting to a web service, or forking a process is inappropriate inside a trigger. If for no other reason than the transaction that spawned the trigger may be rolled back, but you can't roll back those external effects. You may not even be using explicit transactions, but say you send an email in a BEFORE trigger, but the operation fails because of a NOT NULL constraint or something.
Instead, all such work should be done by code in one's application, after one has confirmed that the SQL operation was successful and the transaction committed.
It's too bad that people keep trying to do inappropriate work inside a trigger. There are senior developers at MySQL who promote UDFs to read and write data in memcached. Wow -- I just noticed these have made it into the MySQL 6.0 product!! Shocking!
So here's another attempt at an analogy, comparing triggers and events to the process of a criminal trial:
A BEFORE trigger is an allegation.
An AFTER trigger is an indictment.
COMMIT is a conviction after a guilty verdict.
ROLLBACK is an acquittal after an innocent verdict.
You only want to put the perpetrator in prison after they are convicted.
Whereas an EVENT is the crime itself.