I am trying to implement the Azure service bus with help of java to receive messages from the queue but I am unable to connect to the service bus because of a proxy, I am getting a connection time exception i.e.
Microsoft.azure.servicebus.primitives.ServiceBusException: Error{condition=proton:io, description='Connection timed out: no further information', info=null}
and when I am trying it from my local network(without proxy) it is connecting to azure bus without any problem. I am using the same sample code which Microsoft has provided on GitHub i.e. QueuesWithProxy.java.
How to configure proxy for azure service bus using java?
I try to connect to Microsoft for this problem so I find out that the previous version of queue client supports ConnectivityMode using TCP, HTTP, HTTPS, and AutoDetect. ServiceBus Explorer is using AutoDetect, trying TCP first and then failing over to HTTPS, regardless of the transport mode we were using (SBMP or AMQP).
With the new client this has changed. TransportMode now combines both options and offers Amqp (AMQP over TCP) or AmqpWebSockets (AMQP over WebSockets). There's no AutoDetect mode. You will have to create your clients and specify TransportType as AmqpWebSockets to bypass blocked.
Related
I am looking to rewrite a legacy windows based system to make use of Azure serverless features. Issue I have is that the system has to receive messages coming in via TCP due to the upstream system only supporting that approach. The upstream system then receives the ACK of the handshake as confirmation the message has been accepted.
Are there any Azure services that can accept a TCP message on a none standard port that I could then use to place the message on to an Azure queue? I have found some articles using Service Fabric but nothing less than 3 years old so wonder if there is a better way of doing it currently?
So you can use IoT Hub Protocol Gateway which can be the middle-man for accepting TCP\UDP messages which can then forward the message to Event\IoT Hub. You can then use Event Hub trigger in Azure Functions to process your messages.
You can deploy the Protocol Gateway on an Azure VM.
I have set up the Azure SignalR Service for REST API. There are three modes under settings: Default, Serverless, Classic. I can't find any information about what each of these items sets. The only one thing I got so far, that if I use Azure SignalR for Azure Functions or REST APIs it's preferable to use Serverless option.
From documentation:
Change the Service Mode setting to Serverless only if you are using Azure SignalR Service through Azure Functions binding or REST API. Leave it in Classic or Default otherwise.
Serverless mode is not supported for ASP.NET SignalR applications. Always use Default or Classic for the Azure SignalR Service instance.
Could you please help me to find what each of these options sets?
According to the docs on Github, it determines whether a hub server connected to the SignalR service is needed or allowed:
Default mode requires hub server. When there is no server connection available for the hub, the client tries to connect to this hub fails.
Serverless mode does NOT allow any server connection, i.e. it will reject all server connections, all clients must in serverless mode.
Classic mode is a mixed status. When a hub has server connection, the new client will be routed to hub server, if not, client will enter serverless mode.
Because there isn't a hub server under serverless mode, the things you can do are limited to sending messages to specific clients or broadcast to all clients from a connected client. Also, as there is no hub, messages from clients to SignalR service will be sent over HTTP instead of Websockets, which may have performance concerns as detailed here.
I got a problem getting Azure ServiceBus connected via AMQP through QPID to IBM WAS LibertyProfile.
I followed the tutorial at Microsoft Docs Service Bus Messaging but I got following exception (the URL is obfuscated):
Caused by: Not an AMQP URL amqps://POLICY:ENCODEDKEY#NAMESPACE.servicebus.windows.net
at org.apache.qpid.url.URLHelper.parseError(URLHelper.java:143)
at org.apache.qpid.url.URLHelper.parseError(URLHelper.java:138)
at org.apache.qpid.client.url.URLParser.parseURL(URLParser.java:150)
at org.apache.qpid.client.url.URLParser.<init>(URLParser.java:41)
at org.apache.qpid.client.AMQConnectionURL.<init>(AMQConnectionURL.java:62)
at org.apache.qpid.client.AMQConnectionFactory.<init>(AMQConnectionFactory.java:83)
at org.apache.qpid.ra.QpidResourceAdapter.createFactory(QpidResourceAdapter.java:747)
at org.apache.qpid.ra.QpidResourceAdapter.createAMQConnectionFactory(QpidResourceAdapter.java:656)
In the server.xml I used qpid-ra-6.1.2.rar as resource adapter.
If I use a small example application with the same URL in jndi.properties, the connection works perfect.
The difference between the two solutions is that I use the resource adapter. Am I wrong with using it ?
How would it be better to connect from WAS Liberty via AMQP to Azure Service Bus ?
I'm looking forward to hopefully get some answers or hints.
The answer is that I use a JCA adapter which is not able to connect to a AMQP 1.0 broker. In the example application I use qpid amqp 1.0 client jms.
At the moment there is no amqp 1.0 JCA resource adapter.
Also there is no further work on the resource adapter:
Qpid Jira Ticket 7716
I have a virtual machine on Azure which will listen to messages over the servicebus of Azure. And another developer needs to connect to this servicebus to send messages to my service. To do so, we need to come up with some protocol for this communication system. And I was thinking about using WSDL to make the server something webservice-like, but instead of listening to the standard HTTP ports it would connect to the service bus and within it a topic with subscription, or whatever. I'm still not sure what would be best.
So, is it possible? Has anyone done something similar before? Are there some examples?
Service Bus provides both Brokered and Relayed messaging models. With using Topics/Queues you are essentially sending and receiving message to/from the broker. So you can use APIs/protocols that the broker supports. As an example you can use the NetMessagingBinding from your service/client to send and receive messages through the queue. There is no contract here other than what you put in the BrokeredMessage body and properties values. The application on either end can decode/decipher that info as needed.
In the case of Relayed messaging however you are making a end-to-end connection between the client and the service with Service Bus serving as the proxy in-between for auth, location-transparency and even load-balancing. So here you can use from a variety of RelayBindings such as NetTcpRelayBinding or webHttpRelayBinding but then both the client and the service need to be available at the same time. Here you need the service and clients to be using the same contract.
It seems like the solution to my problem should be easier than it is, which makes me think I'm missing the obvious. I'm trying to test and ensure that a remote client machine can send/receive messages from an Azure Service Bus Queue.
I'm using the sample application provided by Microsoft at https://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-amqp/
The sample application works perfectly fine as long as all ports are open. However, I need the solution to work when only ports 80/443 are available. If I configure Windows Firewall to only allow inbound/outbound traffic on 80/443 it doesn't work. I receive the error "An attempt was made to access a socket in a way forbidden by its access permissions".
The offending line from the sample application is:
sender = factory.CreateMessageSender(entityName);
I've looked at an extraordinary number of sites and one of the suggestions I've found was to set the connectivity mode to Http such as this:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
That doesn't work either.
I'm not trying to setup custom services on either the remote client or Azure hosted roles. I just need them to both be able to send/receive messages via Azure's Service Bus Queues and Topics.
Can anyone point out my flaw?
From my comment above...
I found the answer to why it's not working in my case. The preview library for AMQP in Azure uses a different port then all other documentation I can find. Using the release library it works over https automatically.
Http Connectivity mode doesnt work for Http 1.0. It will work only on Http 1.1...
If you are in Http 1.0 (mostly proxy) you have to open TCP ports (9350-54)