How to avoid invoking background task for every pending raw push delivered to application from wns server when user returns to connected state after being temporarily disconnected in windows runtime 8.1?
I just want to invoke my background task just once for all pending raw pushes?
Related
I'm using flutter_reactive_ble 5.0.2
I wonder is there a queue that make sure that only 1 command execute at a time or should I take care of it in my development?
If for example I call:
subscribeToCharacteristic
then without waiting call to write command that will cause the notification to raise, should I count on the fact that the notification will be finished before the write command (due to a command queue )
We are using Trace32 in our automation environment. I am trying to programmatically control Trace32 and I am able to do it successfully with T32api dlls.
After launching the trace32.exe programmatically (C#/Python 3.7), I wait for 30seconds before communicating with the trace32. During this time, the trace32 finishes booting and ready for remote communication. Is there a way to avoid this hard-coded 30seconds delay by programmatically finding out if the booting is complete?
Just try to connect with function T32_Attach() and repeat until it succeeds.
I have an old Windows Service written in Borland C++ Builder that I need to extend so that it can shutdown itself under certain conditions.
If I shutdown the service manually via the service control manager, it shuts down properly without any problems. So I thought, calling this->DoShutdown(); would be sufficient (this being an instance derived from TService). But this leaves the service in the state "Shutting down...". I could call ExitProcess afterwards, but this creates an entry in the event log that the service has been shut down unexpectedly.
So what is the proper way to make a Borland C++ Windows service shut down itself?
DoShutdown() is called by TService when it receives a SERVICE_CONTROL_SHUTDOWN request from the SCM while Windows is being shut down. DoShutdown() is not intended to be called directly in user code.
The easiest way to have your service terminate itself is to call its Controller() method (either directly, or via its global ServiceController() function), passing either SERVICE_CONTROL_STOP or SERVICE_CONTROL_SHUTDOWN in the CtrlCode parameter. Let the service handle the request as if it had come from the SCM, so it can act accordingly.
I'm trying to achieve following scenario
When a new message arrives to queue manager it should automatically trigger my console application. Then it will fetch that message and write the message in to a file. I already completed this part. But I'm having problem with triggering message queue
Here is how I configured my message queue
I created two queues one is called LocalQueue and other one is InitQueue which is SYSTEM.DEFAULT.INITIATION.QUEUE.
and set "Trigger" properties in my LocalQueue
Then Created trigger monitor
In process definition object I set my console application path
So my problem is, It doesn't work as it expect and I checked my client machine
C:\Program Files (x86)\IBM\WebSphere MQ\errors\AMQERR01.LOG and server machine C:\Program Files (x86)\IBM\WebSphere MQ\errors log files. I couldn't find anything on them
Update
Based on Morag answer I changed my process name
You appear to have named your TriggerMonitor Service object in the queue attribute where you should put the process object name FetchMessages.
The Start Args for your trigger monitor Service object appears to be telling the trigger monitor to monitor the LocalQueue and not the InitQueue.
You need to make sure that the trigger monitor is running and has opened the initiation queue in INPUT(i.e. for GET) mode. Only then queue manager will put a trigger message into initiation queue. Here is what I did to get it working:
I did the setup just like you except for service. I manually started runmqtmc as
SET MQSERVER=<channel name>/TCP/<connname>
runmqtmc -m <qmname> -q <initq>
Put a test message on local queue. That triggered an event and my application started.
I'm trying to write event based ftp server that notifies me when some user uploads any file(users will never do any delete or other stuff, they just upload). Apache ftpServer with ftplets is what I need but it is java based and does not satisfy my environment. So what I'm planning to do is to run vsftpd and another process besides it which listens to IN_CLOSE_WRITE event. When vsftpd close the file descriptor after finishing file upload, my process will be notified and I will do some appropriate action. My questions are:
Is it possible that I miss any file upload?
Is it possible that IN_CLOSE_WRITE fired in other situations that I get inconsistent files instead of ready to use files?
if the incrond service crashes or is stopped you will loose notification during that time
IN_CLOSE_WRITE should work.