I want to create an Azure Function that constantly listens for events from an IP Cam SDK.
Is it possible to do something like this? Or my process would be killed eventually?
while (true)
{
new System.Threading.AutoResetEvent(false).WaitOne();
}
Azure functions differ from traditional services in a way that they don't need to listen for events continuously.
They get invoked each time automatically by triggers
Most common trigger types are:
ServiceBus
HTTP call
Timer
And many others
Check the official documentation here https://learn.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings
Related
I am completely new to Azure and I have a function which is triggered by a service bus queue, the message is a JSON string. Now I want to check if after 3 minutes of receiving the message another arrived.
how do I achieve this?
You may want to use the concept of "Timers in Durable Functions".
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-timers?tabs=csharp
Are you using "azure functions" or do you want to have a function in azure e.g. in a webservice? I am not so sure ;)
In short no! You would have to poll the servicebus message queue yourself to control that behaviour.
https://stackoverflow.com/a/48899686/12040634
What is the scenario that would require you to check for a subsequent message after 3 minutes?
I have a function which is triggered by a service bus queue… I want to check if after 3 minutes of receiving the message another arrived.
Azure Service bus can schedule or defer a message. The two are not the same. Deferring means you need to keep a message and retrieve it at some point yourself. Scheduling, requires creating a new message. But, the two could be combined. Upon receiving of the message (message A), it could be deferred and a new message scheduled (message B), with its payload being the sequence number of the message A. When the message’s B time comes, it will be received by your code and you can request the deferred message B.
This is rather straightforward but you’ll need a few changes to the default Function behaviour. You’ll need to specify that your function needs to be injected with the receiver to be able to defer the incoming message A, and create a sender to post a scheduled message. Also, the function code will now have to distinguish between “data” messages (A) and control messages (B). And that all will only work with the in-process Functions SDK as the newer, Isolated Worker SDK doesn’t support Service Bus SDK types.
But, there are alternatives. You could use Durable Functions to build your mini workflow. Or you could use one of the middleware abstractions for messaging to simplify the implementation with function. MassTransit and NServiceBus with SendLocal()would do.
And good luck with conquering Azure. There are many ways to tackle any problem. Especially with cloud providers.
I have an existing Azure Function that is on a consumption plan
I am writing another function which will call this
Once the existing function is running, it processes files in storage account.
In order the files in my storage account to be processed, we have to manually go into the portal and "wake up" the function by navigating
Is there a way to do this via C# code?
This function is hosted on a consumption based plan
May be this is exact solution you are looking for. I came across this article "An Azure Function to keep other Functions/URLs warmed up" while looking for such solution, haven't tried it yet but I will. If you try it first do post the result.
https://www.sharepointnutsandbolts.com/2018/09/Azure-Function-Warmup-Cold-Start.html
The other approach that I came across is "pinging a health endpoint within your Azure Functions through Azure Monitor." Create a URL ping test. https://learn.microsoft.com/en-us/azure/azure-monitor/app/monitor-web-app-availability
I am in the process of trying these out. Hope this helps.
In serverless computing, Azure functions get executed/spin up whenever you make an invoke, if you want to call another function inside a function you can do via HTTP call.
Durable Functions lets you write stateful functions in a serverless environment. There's nothing built-in in Function Apps to call one HTTP function from other functions without actually making the HTTP call paticularly Function Chaining.
I'm trying to understand the difference between a queue trigger and a service bus queue trigger and which one I need!
I have a asp.net mvc site that is for creating and scheduling classes, which will be represented as a row in a db table. When a class is over I want to send an email to all students asking them to rate their teacher
As far as I'm aware the best way to do this is to create a Azure function that will create and send the emails, but where I'm lost is how to trigger that function at a specific date and time?
Do I use a queue trigger or a service bus queue trigger? What's the difference between the two and which one would be the best for my scenario?
I need to be able to cancel the message in the queue if the class is canceled.
If cancelling scheduled messages is a hard requirement, only Service Bus allows doing that, see this blog.
However, it might be more practical to just add a check whether the class was cancelled at the beginning of your Azure Function, and quit if so.
For the rest of your scenarios, the services will both fit.
Generally, Service Bus has more advanced capabilities and guarantees, but costs more money if you send lots of messages. I usually pick Storage Queues unless I need any of those more advanced features.
I am trying to achieve a pub/sub with azure service bus.
I started with this tutorial and it worked so far:
https://azure.microsoft.com/en-gb/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/
But in my dedicated case i am not exactly sure how i should do it exactly:
I have a web api running on azure web app that is scaled to three instances.
I have a console application client that triggers some messages to a dedicated topic.
What i want to achieve is, that all three instances of the web api get the messages delivered that is send to the message bus.
So it is a fire forget action:
Client sends message to topic
Every subscriber that is CURRENTLY subscribing to this topic should get the message
I am not interested in older messages that were sent when the subscriber was inactive/offline. I am just syncing an in memory cache over these instances so it is really a short living info when i need to know which keys i have to invalidate. but it is important that every subscriber gets the information to avoid stale data.
I am not exactly sure if i have to create a subscription dynamically in the startup code of the web api so that every instance has its own subscription or if i can subscribe all web app instances to the same subscription?
I would like not to dynamically create subscriptions since i don't know when to remove them again (e.g. scaled down to 2 instances instead of three).
but i was unable to find any documentation how to do this and if it is okey that multiple clients subscribe to the same subscription or if i need to create a subscription per client.
I am not exactly sure if i have to create a subscription dynamically in the startup code of the web api so that every instance has its own subscription or if i can subscribe all web app instances to the same subscription?
Service Bus subscribers adopt the Competing Consumer pattern by default. You must create a unique subscription for each Web API instance in order each instance to receive a copy of the message. It will be easiest to do this when the Web API instance starts up.
I would like not to dynamically create subscriptions since i don't know when to remove them again (e.g. scaled down to 2 instances instead of three).
You can configure the subscription to be auto-deleted after being idle for some period of time. "Idle" in this case would mean that the Web API instance has spun down and is no longer attempting to receive messages on the subscription. When creating the subscription set the AutoDeleteOnIdle time span for a brief duration, currently a minimum of 5 minutes. Now you can create a new subscription when the Web API instance starts and know that it will be automatically deleted soon after the Web API instance stops.
I am not interested in older messages that were sent when the subscriber was inactive/offline.
When creating the topic, set the DefaultMessageTimeToLive for a brief duration e.g. 5 seconds. This will ensure that new subscribers don't see old messages.
I have the following message transport scenarios
Client -> Calls SignalR -> Calls NServiceBus -> Process Message internally -> Calls NServiceBus Gateway service with Result -> Calls SignalR Hub -> Updates the client with result.
In choosing whether to use SignalR vs. long polling, I need to know if SignalR is scaleable. So in doing my homework I came across SignalR on Azure Service Bus. The setup is done on the Global.asax application start.
Ultimately I need to be able to do this, from inside an NServiceBus handler:
var context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
context.Clients.Group(group).addMessage(message);
The question is if context will be jacked up, because I'm (potentially) calling it from another machine than the one the client was connected to?
Also what is the sharding schema that the SignalR implementation uses to seed the topics? I know I can configure it to use N-number of topics, but how is it actually determining which message goes to which topics and if it's relevant from an external caller PoV.
You should be able to use GlobalHost.ConnectionManager.GetHubContext in any application where you have registered ServiceBusMessageBus as your IMessageBus via SignalR's GlobalHost.DepenencyResolver. This is done for you if you call GlobalHost.DepenencyResolver.UseServiceBus(...) in the application.
If you do this, a message will be published to Azure Service Bus for each call to addMessage or any other hub method on the IHubContext returned from GetHubContext. If there are subscribed clients connected to other nodes in the web farm, the other nodes will pick up the message from Service Bus and relay it to the subscribed clients.
Which topic a message goes to should not be relevant from the PoV of an external caller. You can use multiple topics to improve throughput, but for most use cases one should be sufficient.
If you choose to use more than one topic, you can think about the topic a message goes to as being essentially random. The only thing that is guaranteed is that messages from the same sender will go to the same topic. This allows SignalR to keep messages from the same sender in order.
Caveat emptor: SignalR has not yet had an official release supporting scale out. The 1.1 version will be the first release to support scale out officially.