What happens when an Azure Logic App is disabled?
Does the current "run" finish, or is it terminated at whatever action is currently on?
In our case, we have a logic app that has a trigger on a message being added to a Service Bus queue ... the Logic App is doing a Peek/Lock read of the message
Various actions, including a SQL Db write, and finishing with a Service Bus complete on the message
If the current run finishes, then we don't have to worry, as that particular message has been "processed"
But if the current run is terminated wherever it is, Service Bus will return the message to the queue after the timeout, and then when the Logic App is re-enabled, we'd re-process the original message from the Service Bus queue
Current in flight runs will finish, but the trigger will stop checking for new events and invoking new runs. You can cancel runs to stop ones that are in progress, but currently is a separate gesture to just disable.
Related
There is a thread group, which contains login request and after that posting of a form. In some cases I get error message in response of form posting request, that user isn't logged in. I use Synchronizing Timer in both HTTP requests(group by=20). Thread is a Stepping Thread Group, so number of active users is incremented in more steps.
No matter whether you use the Synchronizing Timer or not it shouldn't cause any problem with logging in because each thread (virtual user) executes Samplers upside down and separately from the others, the Synchronizing Timer acts as a rendezvous-vous point for multiple users and each of them has its own authentication context.
So the problem with failed login is somewhere else, I would recommend re-running your test with Debug Samplers added and enabled storing of requests and response data so you could inspect the flow and determine the reason for the sporadic login failures.
A message is being dropped to Service bus queue with ScheduledEnqueueTimeUTC and Service Bus Connector in Logic app has trigger set to pick messages from queue at 12:05AM EST EveryDay.
Problem: Logic app has picked the same message twice one with Service bus message properties State='Scheduled' and other with state='Active' with same sequenceNumber. May i know when this happens and how can this be solved.
Problem: Logic app has picked the same message twice one with Service
bus message properties State='Scheduled' and other with state='Active'
with same sequenceNumber. May i know when this happens and how can
this be solved.
Here we discovered one of the workarounds that will meet your needs. To pick and send a message only once, we must set our settings to split on as seen below.
NOTE: I tried using Logic app standard, as this option is not available in Consumption plan
Please refer this MS DOC & SO THREAD for more information .
Environment: SQL Server 2012 Express edition.
Goal: Setup SQL Server Service Broker with external activation, calling a command line app.
What I have done so far: created message types, contracts, initiator and receiver queues and corresponding services. I also did set up a notification queue, notification service and created event notification for the TargetQ. The event notification is configured so that when an event is raised, it should (I thnk) call the NotifySvc letting it know that there is work to be processed in TargetQ. Please feel free to correct me at any point – this is very new to me.
What happens: I have a trigger on a table that (upon insert) creates a message and calls the TargetSvc. The message arrives at the TargetQ happily. And this is where everything stops. I am not sure if the event notification for queue activation is never triggered or what, but the message never makes it to the NotifyQ. Therefore my EA app is never called.
I realize I am skipping a lot of detail around setup and configuration but, as the topic is new to me, I am hoping that you guys see something obvious. Any help is much appreciated.
My website on GAE-Python has a function to calculate some math using Evolutionary Optimization Algorithm, which will be called by an ajax request when the user click a button. Each request usually takes very long time to finish calculation.
I need some way (ajax or other methods) to tell the server to cancel the current request rather than using ajax's xhr.abort() function which does not stop the calculation on server side.
For an early attempt, I have found that GAE has the Request Timer in which the DeadlineExceededError will be raised by the runtime if the request takes too long to finish.
Based on this idea, I would like to ask if there is a way to send a signal to the server to cause the runtime to trigger an interrupt on the request?
You shouldn't be trying to do any long-running tasks synchronously in a handler. This is the perfect candidate for a task queue. The Ajax request should simply push the task onto the queue, and App Engine will process it offline. Tasks get a ten-minute timeout.
You can use memcache or the datastore to pass information to and from your Ajax code. For instance, the task handler could check memcache every few seconds for the existence of a 'stop_processing_FOO' key (where FOO is a unique ID generated by the Ajax when the task is first triggered), and the your 'cancel' button would call a handler to insert that key into memcache.
Similarly, the task could put a 'finished_processing_FOO' key with the associated values into memcache when it finishes, and your Ajax could periodically poll a handler that checks if that key is present, and return the value if so.
I am using Service Broker external activation. I have created event notification for queue (QUEUE_ACTIVATION). Currently making a lots of tests and sometimes my queue gets deactivated.
After enabling queue Event notification does not work anymore and external activator does not start console app.
i found this, but that seems to be something else as "select * from sys.event_notifications" shows that there is already created event notification.
I do drop and create again the same event notification to make it work, but it seems to be wrong..
How can i detect automatically that event notification is not working?
You probably don't RECEIVE and commit the notification from the monitoring queue, causing the notification to go into NOTIFIED state but never transitioning to RECEIVES_OCCURING. See Understanding Queue Monitors.