I have observed that even if i stop a node or a participant by pressing ctr + C, i.e. terminate it...it still shows in the Admin console or 2 minutes or so. Why isnt it immediately derigestered. Is there a way to do so ?
At shutdown of your application, you should clean up the DDS entities, as demonstrated in this piece of example code. In a nutshell, it invokes the following methods:
DDS_DomainParticipant_delete_contained_entities(participant);
DDS_DomainParticipantFactory_delete_participant(DDS_TheParticipantFactory, participant);
If you do not do that, the DDS discovery process will detect by itself after a while that the Participant has gone. The responsiveness of this mechanism is configurable, as explained in the knowledge base article What settings affect DomainParticipant’s liveliness?
Now pressing Ctrl+C normally will not execute the code described above, because the signal will terminate the process right away. As far as I know, the only way to avoid that is to install a signal handler that invokes that clean-up functionality. Here is a gist with some example code on how to install a signal handler: aspyct/signal.c.
Related
I've read the camunda doc, but I don't find anything about it.
I know it doesn't make sense throw something that nobody will catch, but is it possible?
https://docs.camunda.org/manual/7.7/reference/bpmn20/events/signal-events/
https://camunda.com/bpmn/reference/#events-signal
In the Business Process Model And Notation 2.0 specification(can be found at
https://www.omg.org/spec/BPMN/2.0/), P253, in the Table 10.89 - Intermediate Event Types in Normal Flow:
(Signal) This type of Event is used for sending or receiving Signals. A Signal is
for general communication within and across Process levels, across
Pools, and between Business Process Diagrams. A BPMN Signal is
similar to a signal flare that shot into the sky for anyone who might be
interested to notice and then react. Thus, there is a source of the Signal,
but no specific intended target.
Hope that helps.
Yes this is possible. You can model a throwing signal event when there are no receivers. The event will simply throw the signal and continue the normal flow (without anyone ever using the event).
In contrary to that, the catching signal events can not be used without a throwing signal event. If you use a catching signal event without a throwing signal event the process will stop at this event and will never be able to continue.
I've recently started at a new business and some of the processes are becoming a bit of a challenge to map out. Quite frequently we have a process that needs to go "on hold" when an event, which can occur at any point, is triggered. The problem I'm having mapping this out correctly is how to "restart" the process from where it left off, since it can effectively pause/unpause at any point.
Here's what I currently have:
Process Example
Basically, I need to have "Something Happened 2" not fully interrupt the sub-process, it just needs to put it on "hold". The actual situation is essentially that a customer can make a complaint while we handle their overdue bill, so we put the process on hold wherever it was at until we resolve the complaint, and then restart the process.
I'm not entirely sure the best approach to documenting this and couldn't find anything clear in the documentation, since a non-interupting event seems to have the rest of the process still continue forward in parallel.
Any help would be majorly appreciated.
If you really want to restart the whole sub-process from the beginning, then you could frontload an exclusive gateway. Once the complaint is dealt with, you can direct the sequence flow to that gateway, which would restart the sub-process. See below for an example (I have simplified your diagram a bit).
I'm using GPUImageFilter in a chain, and most of the time it works OK. I've recently come across a few random crashes that match the symptoms in this github issue (albeit I'm using GPUImageFilter not live capture or video). I'm trying to find a suitable method that can ensure I've cleared the frame buffer and any other GPUImage-related activities in willResignActive.
Currently I have:
[[GPUImageContext sharedFramebufferCache] purgeAllUnassignedFramebuffers];
Is this sufficient? Should I use something else instead/in addition to?
As indicated there, seeing gpus_ReturnNotPermittedKillClient in a stack trace almost always is due to OpenGL ES operations being performed while your application is in the background or is just about to go to the background.
To deal with this, you need to guarantee that all GPUImage-related work is finished before your application heads to the background. You'll want to listen for delegate notifications that your application is heading to the background, and make sure all processing is complete before that delegate callback exits. The suggestion there by henryl is one way to ensure this. Add the following near the end of your delegate callback:
runSynchronouslyOnVideoProcessingQueue(^{
// Do some operation
});
What that will do is inject a synchronous block into the video processing pipeline (which runs on a background queue). Your delegate callback will block the main thread at that point until this block has a chance to execute, guaranteeing that all processing blocks before it have finished. That will make sure all pending operations are done (assuming you don't add new ones) before your application heads to the background.
There is a slight chance of this introducing a deadlock in your application, but I don't think any of my code in the processing pipeline calls back into the main queue. You might want to watch out for that, because if I do still have something in there that does that, this will lock your application. That internal code would need to be fixed if so.
I was wondering if there was a way that I could get notifications of when a system process from /usr/sbin starts and finishes. Is it possible to attach NSTask to the running process without launching a new one? Preferably without polling please :!
For UI process you can use NSRunningApplication. You can observe the "terminated" property to know when it finishes. You can listen to NSWorkspaceWillLaunchApplicationNotification to know when an application will be launched.
Since you're not running a UI application the above probably won't work. You'll have to use more low level BSD calls. Here's an example of how you can know when an process terminates:
https://developer.apple.com/library/content/technotes/tn2050/_index.html#//apple_ref/doc/uid/DTS10003081-CH1-SUBSECTION10
Good luck!
Scenario:
I have a Distributed-objects-based IPC between a mac application and a launchd daemon (written with Foundation classes). Since I had issues before regarding asynchronous messaging (e.g. I have a registerClient: on the server's root object and whenever there's an event the server's root object notifies / calls a method in the client's proxy object), I did long-polling which meant that the client "harvests" lists of events / notifications from the daemon. This "harvest" is done through a server object method call, which then returns an NSArray instance.
It works pretty well, until for a few seconds, the server object's process (launched thru launchd) starts being labeled red with the "(Not responding)" tag beside it (inside Activity Monitor). Like I said, functionally, it works well, but we just want to get rid of this "Not responding" label.
How can I prevent this "Not responding" tag?
FYI, I already did launchd-based processes before and this is the first time I did long-polling. Also, I tried NSSocketPortNameServer-based connections and also NSSocketPort-based ones. They didn't have this problem. Locking wasn't also an issue 'coz the locks used were only NSCondition's and we logged and debugged the program and it seems like the only locking "issue" is on the harvesting part, which actually, functionally works. Also, client-process is written in PyObjC while server process was written using ObjC.
Thanks in advance.
Sample the process to find out what it's doing or waiting on.
Peter's correct in the approach, though you may be able to figure it out through simple inspection. "Not responding" means that you're not processing events on your event queue for at least 5 seconds (used to be 2 seconds, but they upped it in 10.4). For a UI process, this would create a spinning wait cursor, but for a non-UI process, you're not seeing the effects as easily.
If this is a runloop-based program, it means you're probably doing something with a blocking (synchronous) operation that should be done with the run loop and a callback (async). Alternately, you need a second thread to process your blocking operations so your mainthread can continue to respond to events.
My problem was actually the call for getting a process's PID using the signature FNDR... that part caused the "Not responding" error and it never was the locks or the long-polling part. Sorry about this guys. But thank God I already found the answer.