2

I currently trying to send message to a azure message queue from a company server, but seem to have issues with confirming that the message is received on azure.

Nobody is consuming the message, so it should be placed in the "dead message queue".

Messages that I send from the server does not increment that counter. Message send from a VM does increment the counter?

What could be blocking this? Any way to debug the issue.

None of my exceptions are being triggered..

Beisdes this, I noticed my messages are being received in the dead letter queue and not active message queue.

Nothings is consuming the message, but all azure queue examples I have seen so far mentions that the active message queue should be incremented?

The server does have a proxy for web access, but shoudl that be used aswell for this type of connection?

what is the difference between those two?

I added the stacktrace message: 

The process failed: Microsoft.Azure.ServiceBus.ServiceBusCommunicationException: No connection could be made because the target machine actively refused it ErrorCode: ConnectionRefused ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

but my check for whether the connection isclosed, always returns false.

nano
  • 43
  • 1
  • 7
  • Have you checked that your on prem server can actually reach the queue and is not blocked by your firewall? – Sam Cogan Jun 28 '18 at 09:28
  • How do I do that.. In the code I check whether !program.Azureclient.IsClosed Which returns true. – nano Jun 28 '18 at 09:48

1 Answers1

2

From what I've read, I think Sam Cogan in the comments is right. I think you need to open the appropriate ports to allow Service Bus to communicate.

The article below lists Open Port Requirements:

https://blogs.msdn.microsoft.com/servicebus/2017/11/07/open-port-requirements-and-ip-address-whitelisting/

  • Azure Service Bus requires the use of TLS at all times.
  • It supports connections over TCP port 5671 and over TCP port 5672. The server immediately offers a mandatory upgrade to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
  • Both modern (.Net Standard and Java) clients use AMQP, hence the above guidance applies.
  • The older .NET library has a custom, WCF based protocol that used TCP and port 9354 (called SBMP, Service Bus Messaging Protocol).
  • If you solely use our rest API you may be able to open only port 443.

TL;DR

Try opening outbound TCP ports 5671, 5672 on your firewall, if that doesn't work, try to open port 9354 instead.

P.S.

Here are links as to how you can open ports on your firewalls:

And also here's a link to reasons why messages might be automatically sent to the dead letter queue:

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues#moving-messages-to-the-dlq

  • HeaderSizeExceeded
  • exception.GetType().Name
  • TTLExpiredException
  • Session id is null.
  • MaxTransferHopCountExceeded
  • Specified by application
user9975441
  • 195
  • 9