I've got a layout like this:
EventHubNameSpace
HubA
HubB
HubC
Then I've got app functions:
Product
.AppFunctions
.FunctionA
.FunctionB
.FunctionC
FunctionA is supposed to be a trigger from HubA. (I've checked the Integrations Tab and that's the hub name I've got pointed to).
Same thing with FunctionB, to HubB, etc.
However, when something gets published to HubA, I see the message on FunctionB. The question is why?
Is it that the event hub trigger is firing all of the functions under the "AppFunctions", when any event occurs at the hub namespace level?
They are all set to use $default as their consumer group, but I figured that would be at the event hub name level, not the event namespace level.
Do I need separate function apps, one for each event hub?
So what does has to change to have HubA's triggered messages only go to FunctionA?.
Thanks,
Nick
I can repro the issue in my side. After some researching, I found the cause is that there is a redundant string EntityPath added to the eventhub namespace connection string. Just remove this string then everything is ok.
The steps are as below:
1.Nav to azure portal, you azure function -> Configuration -> Application settings. Then click on the name of yourEventhubNameSpace_RootManageSharedAccessKey_EVENTHUB, remove the EntityPath from it. The screenshot is as below:
Then click save button. After this changes, each function like FunctionA / FunctionB / FunctionC should work correctly.
Related
I have function app where I have one HttpTrigger and 3 BlobTrigger functions. After I deployed it, http trigger is working fine but for others functions which are blob triggers, it gives following errors
"Stopping the listener 'Microsoft.Azure.WebJobs.Host.Blobs.Listeners.BlobListener' for function " for one function
Stopping the listener 'Microsoft.Azure.WebJobs.Host.Listeners.CompositeListener' for function
" for another two
I verified with other environments and config values are same/similar so not sure why we are getting this issue in one environment only. I am using consumption mode.
Update: When file is placed in a blob function is not getting triggered.
Stopping the listener 'Microsoft.Azure.WebJobs.Host.Blobs.Listeners.BlobListener' for function
I was observed the same message when working on the Azure Functions Queue Trigger:
This message doesn't mean the error in function. Due to timeout of Function activity, this message will appear in the App Insights > Traces.
I have stopped sending the messages in the Queue for some time and has been observed the traces like Web Job Host Stopped and if you run the function again or any continuous activity is present in the Function, then this message will not appear in the traces.
If you are using elastic Premium and has VNET integrated, the non-http trigers needs Runtime scale monitoring enabled.
You can find Function App-->Configuration--> Function runtime settings and turn on Runtime scale monitoring.
If function app and storage account which holds the metadata of the function Private linked, you will need to add the app settings WEBSITE_CONTENTOVERVNET = 1.
Also, make sure you have private linked for blob, file, table and queue on storage account.
I created ticket with MS to fix this issue. After analysis I did some code changes as
Function was async but returning void so changed to return Task.
For the trigger I was using connection string from app settings. But then I changed it to azureWebJobStorage(even though bobth were same) in function trigger attribute param
It started working. So posting here in case it is helpful for others
I created a topic "Messages" in my service bus instance, and added a new subscription to it. I can send messages to this topic and the Azure Function v3 trigger is activated just fine. The message is received and displayed in an instant.
When I add an sql filter to filter messages for a subscription it is not working anymore.
What I did so far.
Created an sql filter in the azure portal:
sys.Label = "Test" -> Not working as no messages are received anymore, even though I verified that the Label attribute is set.
sys.Label != "Test" Not working as no messages are received anymore, even though I verified that the Label attribute is set and not matching "Test"
sys.To = "Test" -> Not working, no messages are received. Verified that the messages contain the To member.
sys.Label is not Null -> This is strangely working.
What am I doing wrong here?
As stated in the comment, the solution to this question can be found in the Microsoft Q&A.
To prevent a loss of this solution I am going to post it here too:
The SQL filter value should be in single quotes 'test'
Example : sys.To = 'test'
Make sure that you are defining the message system properties while
sending the message to topic.
Source
If someone is caught off guard by the red single quotes. They are just red, but don't indicate that something is wrong with it. It will just work fine.
I have deployed a change to a durable function product into Azure DevOps and part of the work was to rename an activity function.
However the warning below is appearing in the log stream containing the old name for the function.
[Warning] Activity function 'PublishNotification' does not exist..
InstanceId: . Function: PublishNotification.
This function publishes a message to a Service bus topic, and there is definitely now no reference to that function name anywhere in the code.
Any ideas where this might be coming from?
From your description, it seems that your function name has been changed, the orchestrator function listener and other function listeners are been deregistered:
https://github.com/Azure/azure-functions-durable-extension/blob/f6f1dce716b68d8baaa99ed64a9db1306577c58d/src/WebJobs.Extensions.DurableTask/Listener/DurableTaskListener.cs#L44-L54
But the orchestrator function is still running, and it cannot find your previous function name:
https://github.com/Azure/azure-functions-durable-extension/blob/f6f1dce716b68d8baaa99ed64a9db1306577c58d/src/WebJobs.Extensions.DurableTask/DurableOrchestrationContext.cs#L385
If you restart the function app and let everything start again, can you still reproduce this error?
I went into the Azure web job storage queues and had a look around. Turns our there was an old message (about 4 days old) stuck in one of the queues and when that was cleared out the warning messages disappeared too.
How can we move a service bus queue message to the dead letter through service bus queue trigger function
https://github.com/Azure/azure-webjobs-sdk/issues/1986#issuecomment-433960534
In v3, you can bind to the MessageReceiver class, which exposes methods like DeadLetter, Abaondon, Complete, etc. Example:
public static async Task ProcessMessage(
[ServiceBusTrigger("myqueue")] string message, int deliveryCount,
MessageReceiver messageReceiver,
string lockToken)
{
. . .
await messageReceiver.DeadLetterAsync(lockToken);
. . .
}
In this example, the message is bound as a string and the various message properties including lockToken are bound as params. You can also bind the message as a Message Type and access the requisite message properties from there. In v2 the ServiceBus SDK exposed these message methods directly on the BrokeredMessage class itself, but in the latest version of their SDK those methods no longer exist, meaning you have to bind to MessageReceiver to access them.
Edit you also need to set AutoComplete to false when you do this. https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus-trigger?tabs=csharp#configuration
I have not tried it but what you can do is set the MaxDeliveryCount property on the queue to 1 and then throw an exception in the function as soon as it is triggered. That way the message's delivery count will increase by 1 and Service Bus will automatically dead letter the message.
In latest versions (5.5.1 for me), you must use the ServiceBusMessageActions class from the Microsoft.Azure.WebJobs.ServiceBus namespace. It looks like this:
[FunctionName("MyFunction")]
public static async Task Run(
[ServiceBusTrigger("myQueue", Connection = "myConnection")]
ServiceBusReceivedMessage message,
ServiceBusMessageActions messageActions)
{
...
await messageActions.DeadLetterMessageAsync(message);
...
}
The NuGet package you want to use is Microsoft.Azure.WebJobs.Extensions.ServiceBus.
Reading the Dead Letter Queue messages is by creating the Azure Function Trigger in the Azure portal. In the Function, provide the name of the DLQ as “QueueName/$DeadLetterQueue” as shown in the below image
Note: If you want to access the undelivered message from the Topic then, the syntax of reading the Dead Letter Queue will be “TopicName/Subscriptions/SubscriptionName/$DeadLetterQueue”.
Now, define what should be done with the DLQ messages. Here, as shown in the below screenshot, we are sending the DLQ messages of “myqueue” to the Topic named of “queue” using the Azure Service Bus
In this manner, we can handle the DLQ messages as required very easily using the Azure Functions.
I have also asked this question in the MSDN Azure forums, but have not received any guidance as to why my function goes idle.
I have an Azure function running on a Consumption plan that goes idle (i.e. does not respond to new messages on the ServiceBus trigger queue) despite following the instructions outlined in this GitHub issue:
The configuration for the function is the following json:
{
"ConnectionStrings": {
"MyConnectionString": "Server=tcp:project.database.windows.net,1433;Database=myDB;User ID=user#project;Password=password;Encrypt=True;Connection Timeout=30;"
},
"Values": {
"serviceBusConnection": "Endpoint=sb://project.servicebus.windows.net/;SharedAccessKeyName=SharedAccessKeyName;SharedAccessKey=KEY_HERE",
}
}
And the function signature is:
public static void ProcessQueue([ServiceBusTrigger("queueName", AccessRights.Listen, Connection = "serviceBusConnection")] ...)
Based on the discussion in the GitHub issue, I believed that having either a serviceBusConnection entry OR an AzureWebJobServiceBus entry should be enough to ensure that the central listener triggers the function when a new message is added to the ServiceBusQueue, but that is proving to not be the case.
Can anyone clarify the difference between how those two settings are used, or notice anything else with the settings I provided that might be causing the function to not properly be triggered after a period of inactivity?
I suggest there are several possible causes for this behavior. I have several Azure subs and only one of them had issues with Storage/Service Bus-based triggers only popping up when app is not idle. So far I have observed that actions listed below will prevent triggers from working correctly:
Creating any Storage-based trigger, deleting (for any reason) the triggering object and re-creating it.
Corrupting azure function input parameters by deleting/altering associated objects without recompiling a function
Restarting functions app when one of the functions fails to compile/bind to trigger OR input parameter and hangs may cause same problems.
It has also been observed that using legacy Connection Strings setting for trigger binding will not work.
Clean deploy of an affected function app will most likely solve the problem if it was caused by any of the actions described above.
EDIT:
It looks like this is also caused by setting Authorization/Authentication on the functions app, but I have not yet figured out if it happens in general or when Auth has specific configuration. Tested on affected Azure sub by disabling auth at all - function going idle after 30-40 mins, queue trigger still initiates an execution, though with a delay as expected. I have found an old bug related to this, but it says issue resolved.