Azure Service Bus with NSB 7 and .net core

gjek · September 3, 2018, 8:02pm

I uploaded the application i am using in .net core.

gjek · September 3, 2018, 8:10pm

can you please outline it here what you are saying here. I have not receiving anything regarding support case

SeanFeldman · September 3, 2018, 8:30pm

Support emails are coming from support@particular.net. If you have that email blocked, you will not receive anything. Please check your spam as well.

If you have old ASB endpoint publishing and the new ASBS endpoint receiving locally, but not in Azure it could mean that they are not using the same namespace.

Check the namespace used by publisher and subscriber is the same namespace when deployed to Azure
If deployed to IaaS (VMs), validate there are no blocked ports (TCP 5671).
The code you’ve supplied is showing the subscriber, but not the publisher. If you can, provide a simple repro that has nothing to do with your project and scoped solely to pub/sub issue.

In case it’s not a namespace, I’d ask to share your namespace infor, but this should NOT be done over a public forum… hence the support case. I’m quite confident there’s an issue with the deployment rather than the transport. The code is the same code and should work.

gjek · September 3, 2018, 8:40pm

Excuse my ignorance but I have not blocked that email and I have not received no email from support@particular.net

I don’t think it is a issue with the namespace. THe publisher is using the same code as the .net core one
the following is the namespace:
Resident.DomainEvents.FutureResidentCreated

gjek · September 3, 2018, 8:42pm

Better yet, provide me with an exmaple with NSB 6 and NSB 7!

SeanFeldman · September 3, 2018, 10:04pm

Absolutely. Here’s a result of a sample app you can find here.
You will need a connection string specified via environment variable called AzureServiceBus_ConnectionString or via any other means.

In case you find any bugs with the ASBS transport, please raise those in the following repository.

Would also suggest to review why you haven’t received support emails as that will affect you in the future when you’ll try to contact support.

Cheers.

gjek · September 3, 2018, 10:33pm

alright cool.

One thing, I notice that the publish is different. In NSB 6 I am using JsonSerializer but I see that you are using NewtonsoftSerializer. In NSB 6 I am using NServiceBus.Azure.Transports.WindowsAzureServiceBus 7.2.6 and you are using 8.0.3

would that be the problem?

gjek · September 3, 2018, 10:59pm

Can you test with those settings to see if it works

SeanFeldman · September 4, 2018, 12:08am

Updated the sample to use sender with NSB v6 and unobtrusive mode (removed Messages project).
Note use of RemoveAssemblyInfoFromMessageMutator - this is to ensure that messages coming from Publisher assembly can be processed by Subscriber. Pub/sub works fine.

Note: 7.2.6 is not the latest supported patch version. You should use 7.2.12

In caseit’s still not working, I highly recommend to use support channel to determine what’s different about your setup.

gjek · September 4, 2018, 12:10pm

I have setup my project exactly as yours. But I still cannot receive messages once it goes over to azure. I consume messages if i run everything locally.

I will upgrade NServiceBus.Azure.Transports.WindowsAzureServiceBus to 7.2.12 and see if that fixes it

gjek · September 5, 2018, 8:31am

I upgrade to packages 7.2.12 and still not working. Below is the packages that I am using. I have opened the firewall for the port and nothing.

package id=“NServiceBus” version=“6.3.4” targetFramework=“net461” />
package id=“NServiceBus.Autofac” version=“6.0.1” targetFramework=“net461” />
package id=“NServiceBus.Azure.Transports.WindowsAzureServiceBus” version=“7.2.12” targetFramework=“net461” />
package id=“NServiceBus.CustomChecks” version=“2.0.0” targetFramework=“net461” />
package id=“NServiceBus.Heartbeat” version=“2.0.0” targetFramework=“net461” />
package id=“NServiceBus.Metrics” version=“2.0.0” targetFramework=“net461” />
package id=“NServiceBus.Metrics.PerformanceCounters” version=“2.0.0” targetFramework=“net461” />
package id=“NServiceBus.Metrics.ServiceControl” version=“2.0.1” targetFramework=“net461” />
package id=“NServiceBus.Serilog” version=“3.0.3” targetFramework=“net461” />

gjek · September 5, 2018, 10:25am

Seems to be a general issue with Azure Service Bus, I check with other colleagues and they are not able to consume messages for newly created subscriptions

gjek · September 5, 2018, 10:51am

when i start my .net core app i have the following

gjek · September 5, 2018, 11:13am

With NSB 6

any ideas why I would get 409?

I believe that the issue that I cannot get events

danielmarbach · September 5, 2018, 12:22pm

Hi

I used the sample from @SeanFeldman, setup the V6 endpoint in the cloud for simplicity reasons in IaaS and ran the v7 subscriber on my local box. As you can see below the communication works fine

So I think it has something to do with the network connection between the endpoint running in the cloud and your local environment.

Regards
Daniel

gjek · September 5, 2018, 12:44pm

@danielmarbach

If it run on my local machine it works fine. I can consume events. However I took the SubscriberASB and waiting for events to be consumed and the handler does not fire. NSB in Azure sending events

Now I dont know if it is NSB or AzureServiceBus

danielmarbach · September 5, 2018, 12:56pm

Hi

As much as I would wish to be a Server and PaaS whisperer, I’m not. It seems that we are stuck in a ping pong between us repeating it works in our repros and you repeating it doesn’t without giving us much more details. So I suggest we look into this deeper by going into a call (send me an email to daniel dot marbach at particular dot net) and discuss this issue further in detail. If you prefer continuing on this manner in an asynchronous fashion I suggest you provide us more details like

Log files
Check the topology and the rules on the broker if the subscription for the endpoint exists
Region
and anything else you can give us to be able to track this down

Regards
Daniel

danielmarbach · September 5, 2018, 2:24pm

Short update:

Geremia and I had a call. The scenario was the following:

When he ran his .NET Core application together with the v6 application on the same box the event was delivered. When he ran over Azure it was not. To verify he executed a local integration test that calls a gateway. That gateway sends a command to an endpoint that handles the command. Once the command is handled an event was supposed to be published which the .NET Core Application was supposed to receive but it never did. We checked for competing consumer scenario which was not the case. We found multiple publishes in an event store subscription notifier that are not awaited. I suggested to add GetAwaiter().GetResult() calls for now and then verify again. I also highlighted that we have now an analyzer package that detects such cases in the code

gjek · September 5, 2018, 2:39pm

Thanks for the call @danielmarbach

We gonna update the code base and re-test.

Thanks

alexander-nanay · December 5, 2019, 2:46pm

I understand this topic is quite old, but just wanted to confirm GetAwaiter().GetResult() on publish solves the issue.

It’s quite weird because incorrect publishing somehow always produce a message to the Azure queue created by NSB 6 listener, but not to the queue created with NSB 7 listener. This incorrect publishing was working for years with NSB 6.
Hope this thread will help someone to not spend days trying to figure out what’s wrong.