I have reviewed the jBASE documentation on triggers but I have some additional questions on managing them.
Does a trigger use up a license seat? If so, continuously, or only upon action?
Does a trigger continue running in the background like a phantom process?
How do we manage them i.e. pause, stop, restart a trigger?
Do I need to restart the trigger after a reboot?
A trigger is an extension of the file I/O and the process doing the I/O would be using a jBASE license at the time of the I/O, but no additional license is needed for the trigger itself.
The trigger again is an extension of file I/O, so no it is not background or phantom process, but is simply a process that runs at the trigger point
Triggers are not started or stop, only defined. If a trigger is defined for a trigger point, during file I/O that trigger will run.
Triggers are integral to the file I/O and therefore do not need to be "restarted"
Related
Ok, so I get the gist of MediaFoundation:
When I start my App I create an IMFMediaSession.
When I want to play a file I create an IMFMediaSource, create the necessary IMFTopology, and I set it to the IMFMediaSession. Depending on the flag used (dwSetTopologyFlags) the new media source will either play immediately or just get added to a queue to be played by the MediaSession when the existing topologies/mediaSources are done playing.
Now my issue is cleaning up after old media sources.
Is there an event that is sent by the MediaSession right before the topology used is about to be removed? That way I could access the media source from there and call ShutDown on it (thus avoiding memory leaks) without having to keep references to previous mediaSessions myself in my code.
//=============================================================================== Update:
According to MSDN:http://msdn.microsoft.com/en-us/library/windows/desktop/aa372153%28v=vs.85%29.aspx
I need to call ShutDown on any IMFMediaSource I create, before releasing it.
With this in-mind, mixing MFSESSION_SETTOPOLOGY_FLAGS (immediate/clear_current with no flags) can cause a memory-leak, as the Session removes topologies from its queue without my application having the chance to call shutdown on their sources.
Also, if I call Shutdown on the current mediaSource before the next mediaSource's topology has been set (i.e. before I get the MESessionTopologyStatus event) then I can't playback the next mediaSource. Why? I don't know, msdn does not explain what resources are released when I call shudown on a mediaSource, so I guess something I still need in order to play the next mediaSource is being released...
My experience is that if you do not call Shutdown on Source, you will have memory leak. Check my project MFNode. There is a custom MediaSession (MFNodePlayer project).
If you uncomment the call to Shutdown on the source, you will see memory leak.
A lot of source expect you call Shutdown because you need to wait stop message from the source (they are usually asynchronous).
If you try to use the the source before it stops, you will face some strange error/behaviour and memory leak.
You have to wait the source to stop, in order to have a stable application. And calling Shutdown on source is here for that.
Colleagues, I have need to run a script/program on certain basic OS level events. In particular when a file in Windows is opened. The open may be read-only or to edit, and may be initiated by a number of means, either from windows explorer (open or ), be selected from a viewing or editing application from the native file chooser, or drag-n-drop into an editing or viewing application.
Further, i need the trigger to "hold" the event from completing the action until the runtime on the program has completed. The event handler program may return a pass state, or fail state. If fail state has been returned, then the event must disallow the initially requested action.
Lastly, I need to add to the file in question a property or attribute that will contain metadata that will be used by the above event trigger handler program to make a determination as to the pass/fail condition that will ultimately determine if the user is permitted to open the file.
Please note that this is NOT a windows event log situation, but one at the OS level file open event.
thanks very much for your help.
Edit
What I had hoped that someone was aware of was an OS level trigger, similar to how you can enable a trigger on an event-log writer occurance in Windows (ie: send an email, run a script when an event hits the event logger).
The application environment I work in, a PLM system, allows for event handling. So, when a user initiates an action, say a checkout of a file from an object, there are 3 available handlers or triggers that can be programmed. The "check" or "pre-action" trigger is a process that fires when the user starts initiates the event, but before the system permits it to be processed. So, one can block or otherwise alter the response of the system programmatically based on some condition, like user context.
I have also enabled startup/shutdown script firing via group policy, so i can delay a server shutdown until a database has closed properly. This was done in Windows server 2003. So, with that hook, i could manage shutdown or startup.
Hence, I had hoped someone might be aware of an OS trigger that would do the same for a file-open operation. This would be deployed on all workstations and desktops.
Again, if there are any ideas, it would be greatly appreciated.
Thanks again.
regards,
j
A couple strategies come to mind. One is to run the app with your own DLL to intercept API calls like WriteFile. Another would be to run the app under the debugger interface.
I need to track to a log when a service or application in Windows is started, stopped, and whether it exits successfully or with an error code.
I understand that many services do not log their own start and stop times, or if they exit correctly, so it seems the way to go would have to be inserting a hook into the API that will catch when services/applications request a process space and relinquish it.
My question is what function do I need to hook in order to accomplish this, and is it even possible? I need it to work on Windows XP and 7, both 64-bit.
I think your best bet is to use a device driver. See PsSetCreateProcessNotifyRoutine.
Windows Vista has NotifyServiceStatusChange(), but only for single services. On earlier versions, it's not possible other than polling for changes or watching the event log.
If you're looking for a user-space solution, EnumProcesses() will return a current list. But it won't signal you with changes, you'd have to continually poll it and act on the differences.
If you're watching for a specific application or set of applications, consider assigning them to Job Objects, which are all about allowing you to place limits on processes and manage them externally. I think you could even associate Explorer with a job object, then all tasks launched by the user would be associated with your job object automatically. Something to look into, perhaps.
I'm very interested in the answer to another question regarding watchdog timers for Windows services (see here). That answer stated:
I have also used an internal watchdog system running in another thread. That thread looks at the main thread for activity like log output or a toggling event. If the activity is not seen then the service is considered hung and I shutdown the service.
In this case you can configure windows to auto-restart a stopped service and that might clear the problem (as long as it's not an internal logic bug).
Also services I work with have text logs that are written to a log. In addition for services that are about to "sleep for a bit", I log the time for the next wake up. I use MTAIL to watch a log for output."
Could anyone give some sample code how to use an internal watchdog running in another thread, since I currently have a task to develop a windows service which will be able to self restart in case it failed, hung up, etc.
I really appreciate your help.
I'm not a big fan of running a watchdog as a thread in the process you're watching. That means if the whole process hangs for some reason, the watchdog won't work.
Watchdogs are an idea lifted from the hardware world and they had it right. Use an external circuit as simple as possible (so it can be provably correct). Typical watchdogs simply ran an timer and, if the process hadn't done something before the timer expired (like access a memory location the watchdog was watching), the whole thing was reset. When the watchdog was "kicked", it would restart the timer.
The act of the process kicking the watchdog protected that process from summary termination.
My advice would be to write a very simple stand-alone program which just monitored an event (such as file update time being modified). If that event didn't occur within the required time, kill the process being watched (and let Windows restart it).
Then have your watched program periodically rewrite that file.
Other approaches you might want to consider besides regularly modifying the lastwritetime of a file would be to create a proper performance counter or even a WMI object. We do the later in our build infrastructure, the 'trick' is to find a meaningful work unit in the service being monitored and pulse your 'heartbeat' each time a unit is finished.
The advantage of WMI or Perf Counters over a the file approach is that you then become visible to a whole bunch of professional MIS / management tools. This can add a lot of value.
You can configure from service properties to self restart in case of failure
Services -> right-click your service -> Properties -> First failure : restart the service -> Second failure : restart the service -> Subsequent failure : restart
The workflow is being published as a wcf service, and I need to guarantee that workflows execute sequentially. Is there a way--in code or in the config--to guarantee the runtime doesn't launch two workflows concurrently?
There is no way to configure the runtime to limit the number of workflows in progress.
Consider though that its the responsibility of the workflow itself to control flow. Hence the workflow itself should have means to determine if another instance of itself is currently in progress.
I would consider creating an Activity that would transactionally attempt to update a DB record to the effect that an instance of this workflow is in progress. If it finds that another is currently in progress it could take the appropriate action. It could fail or it could queue itself using an EventActivity to be alerted when the previous workflow has completed.
You probably will need to check at workflow start for another running instance.
If found, cancel it.
I don't agree that this needs to be handled at the WorkflowRuntime level. I like the idea of a custom Activity, sort of a MutexActivity that would be a CompositeActivity that has a DB backend. The first execution would log to the database it has a hold of the mutex. Subsequent calls would queue up their workflow IDs and then go idle. When the MutexActivity completes, it would release the Mutex, load up the next workflow in the queue and invoke the contained child activities.