I've been trying for a week now to deploy a Redis Container as a Azure Web App Service, but I can't manage to connect to it, after a few tries some of the logs I got are listed bellow:
The handshake failed due to an unexpected packet format redis
Protocol error, got "H" as reply type byte. Please report this.
Redis error Error: getaddrinfo ENOTFOUND https://*************.azurewebsites.net
Some of the things I tried:
Different doors (80, 6379, random ones I saw in logs)
Different TLS versions
Force https connection
Does anyone of you know if it's possible to do it? I know there's Azure Redis but it's too pricey for a test.
Thanks alot
just figured out.
You actually have to deploy your container image using container instances, pointing the port 6379/TCP.
I did it and it worked fine.
Related
We have a weird networking issue.
We have a Hyperledger Fabric client application written in Node.js running in Kubernetes which communicates with an external Hyperledger Fabric Network.
We randomly get timeout errors on this communication. When the pod is restarted, all goes good for a while then timeout errors start, sometimes randomly fixed on its own and then goes bad again.
This is Azure EKS, we setup a quick Kubernetes cluster in AWS with Rancher and deployed the app there and same timeout error happened there too.
We ran scripts in the same container all night long which hits the external Hyperledger endpoint both with cURL and a small Node.js script every minute and we didnt get even a single error.
We ran the application in another VM as plain Docker containers and there was no issue there.
We inspected the network traffic inside container, when this issue happens, we can see with netstat a connection is established but tcpdump shows no traffic, no packages are even tried to be sent.
Checking Hyperledger Fabric SDK code, it uses gRPC protocol buffers behind the scenes.
So any clues maybe?
This turned out to be not Kubernetes but dropped connection issue.
gRPC keeps connection open and after some period of inactivity intermediary components drop the connection. In Azure AKS case this is the load balancer, as every outbound connection goes through a load balancer. There is a non configurable idle timeout period of 4 minutes after which load balancer drops the connection.
The fix is configuring gRPC for sending keep alive messages.
Scripts in the container worked without a problem, as they open a new connection every time they run.
Application running as plain Docker containers didnt have this issue since we were hitting endpoints every minute hence never reaching idle timeout threshold. When we hit endpoints every 10 minutes, timeout issue also started there too.
We have a Nodejs server that communicates with the websocket protocol (WebRTC, socket.io).
During our development on Heroku, we did not encounter any particular problem.
However, we encountered problems during the deployment of our application on Azure:
The client / server communication is unstable, after analysis we noticed that there is a failure to communicate in websocket and that the transport protocol used is 'polling':
websocket.js:112 WebSocket connection to
'wss://hote.fr/socket.io/?EIO=3&transport=websocket&sid=EgjKLAtp89wrBKMzAAAG'
failed: Error during WebSocket handshake: Unexpected response code:
503
When you activate the "Websocket" function on the administration, the site becomes even more unstable and very long and communication is impossible. The problem of websocket communication is not solved with this function. Example
After having informed us we did disable the websockets in the web.config but without change.
Note that with the same code, everything works well under heroku and the protocol used is websocket.
Has anyone ever encountered this problem, and has a solution?
I'm sorry about my English.
Thank you in advance for your time.
You need do the following to make it work on Azure App Service.
Enable Web sockets via the Azure portal.
Disable the IIS WebSocket module to allow Node.js to provide its own
WebSocket implementation by add this to your web.config file:
<webSocket enabled="false" />
Tell Socket.IO to use WebSocket only instead of a few XHR requests by adding this to the Node.js server:
io.set('transports', ['websocket']);
And on the client add this:
var socket = io({transports: ['websocket']});
Try the suggestions outlined by Aaron to narrow the issue, I would like to highlight a few restrictions on the Azure Sandbox to help isolate the issue further:
1.In App Service, limits are enforced for the maximum number of outbound connections that can be made for each VM instance.
As mentioned in the document Cross-VM numerical limits:
“These limits apply only for customers of Basic or higher plans; in other words, customers running on their own dedicated VMs. These limits are there to protect the entire VM even though one particular site may be with its limits described above. The limits are different depending on the size of VM configured.”
This error also might occur if you try to access a local address from your application.
As mentioned in the document Local address requests:
“Connection attempts to local addresses (e.g. localhost, 127.0.0.1) and the machine's own IP will fail, except if another process in the same sandbox has created a listening socket on the destination port.
Rejected connection attempts, such as the following example which attempts to connect to 127.0.0.1:80, from .NET will result in the following exception:
Exception Details: System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80.”
3.For more information about outbound connections in your web app, see the blog post about outgoing connections to Azure websites.
I was working fine with cloudamqp until all of a sudden wascally/rabbot stopped being able to connect to my endpoint. I have installed RabbitMQ locally and my system works fine. I have since then tried to setup a RabbitMq instance on Heroku via bigwig, to no avail. The endpoints I'm using should be fine and I also installed amqp.node and node-amqp to test if maybe it was a problem with rabbot. However none of these can connect either.
Any idea what the problem can be?
the most common cause is connection timeout. with all my wascally code, hosting on cloudamqp (with heroku, digital ocean or otherwise), i have to set a connection timeout much higher than the default for it to work.
this can be done with the connection_timeout parameter on the connection string url (https://www.rabbitmq.com/uri-query-parameters.html)
for example:
var conn = "amqp://myuser:mypassword#server.cloudamqp.com/my-vhost?connection_timeout=30"
this will set a connection timeout of 30 seconds
I have couchdb running on a Linux Ubuntu 14.04 VM and a .net Web application running under Azure Web Apps. Under our ELMAH logging for the web application I keep getting intermittent errors:
System.Net.Sockets.SocketException
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [ipaddress]:5984
I've checked the CouchDB logs and there isn't a record of those requests so I don't believe it's hitting the CouchDB server, I can confirm this by looking at the web server logs on Azure and see the Error 500 response. I've also tried a tcpdump however with little success (another issue logging tcpdump to a separate disk keeps failing due to access denied)
We've previously ran CouchDB on a Windows VM with no issues so I wonder if the issue relates to the OS connection settings for tcp and timeouts
Anyone have any suggestions as to where to look or what immediately jumps to mind?
I've a sitecore azure deployment 2.0. Unfortunately, when I try to run this from company network I get the error below:
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond 213.199.180.206:80
When I try below on the same machine it works:
http://www.google.com
https://www.google.com
Wondering what exactly is causing the above issue given both 443 and 80 works well via IE.
Thanks.
Definitely sounds like a corporate firewall/gateway problem. Have written a blog post with my experiences of just these types of issues. http://reservoirdevs.wordpress.com/2013/10/18/sitecore-azure-walkthrough-and-gotchas/
My solution was to try from outside the corporate network. It then worked fine.
This sounds like your firewall on your Azure machine is not set to allow incoming http traffic on port 80. Although there could be a lot of other reasons for this timeout.