I have deployed console application as webjobs on Azure which is getting data from ftp server but when run the console application on local it works fine but when deploy it on Azure it throws exception IO Exception while connecting to FTP server.
I deployed a webjob to get data from kudu via FTP, it worked fine on local but couldn't get data on the azure as same as you.
public static void main(String[] args) {
FTPClient client = new FTPClient();
try {
client.connect("url");
client.login("username", "password");
if (client.isConnected()) {
// Obtain a list of filenames in the current working
// directory. When no file found an empty array will
// be returned.
String[] names = client.listNames();
for (String name : names) {
System.out.println("Name = " + name);
}
FTPFile[] ftpFiles = client.listFiles();
for (FTPFile ftpFile : ftpFiles) {
// Check if FTPFile is a regular file
if (ftpFile.getType() == FTPFile.FILE_TYPE) {
System.out.printf("FTPFile: %s; %s%n",
ftpFile.getName(),
FileUtils.byteCountToDisplaySize(ftpFile.getSize()));
}
}
}
client.logout();
} `
Per my experience, it's due to the Kudu Network restriction. Webjob runs in its sandbox, the only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports.
Applications can create a socket which can listen for connections from within the sandbox. For example, two processes within the same app may communicate with one another via TCP sockets; connection attempts incoming from outside the sandbox, albeit they be on the same machine, will fail. Here is the reference.
If you still have questions , please let me know.
Related
I have an ASP.NET MVC 5 application running in the azure german cloud as Azure Web App (single instance - Standard S3 size).
I'm calling a non azure hosted REST/SOAP service on a particular host and the web requests either succeed promptly or timeout after 21 / 42 seconds.
I've load tested the requests and the percentile of requests timing out is between 20 and 80.
One particular remarkable property of the timeout is, that they occur after exactly 21 or 42 seconds (this is serious, no reference to hitchhiker's guide to the galaxy intended).
Calling a different service from the web app works just fine, temporarily at least.
We've already checked the firewall of the non azure service and if the timeout occurs, not a single packet reached the host.
This issue occurred once in the past one year ago and support was unable to tell what the cause was until the issue suddenly went away roughly two weeks after first occuring, so the ticket got closed as fixed itself but now its back.
The code is using https://github.com/canton7/RestEase (uses HttpClient underneath) and looks like
[Header("Content-Type", "application/json")]
public interface IApi
{
[Post("/Login")]
Task<LoginToken> Login([Body]LoginRequest request);
}
private static Dictionary<string, IApi> ApiClientsByHost = new Dictionary<string, IApi>();
private IApi GetApiForHost(string host)
{
if (!ApiClientsByHost.TryGetValue(host, out var client))
{
lock (ApiClientsByHost)
{
if (!ApiClientsByHost.TryGetValue(host, out client))
{
ApiClientsByHost[host] = client = RestClient.For<IApi>(host);
}
}
}
return client;
}
var client = GetApiForHost("https://production/");
var loginToken = await client.Login(new LoginRequest { Username = username, Password = password });
By different service, i mean using "https://testserver/" instead of "https://production/" (testserver is located in a different data center with different IP and all).
The API authentication is passing a token via query but it timeouts already before being able to get a token.
The code is caching the IApi to avoid the TCP starvation problems of disposing HttpClients (but i've never run into port exhaustion).
Restarting the app does not resolve the issue and the issue only occurs to production currently (but a year ago, when this issue occurred on production, we've switched to testserver which worked initially but after some time, ran into the same problem)
EDIT: Found some explanation in the last answer as to where those magical 21 seconds are comming from.
EDIT: One way i've found to workaround is, is to setup a azure vm with a proxy on it and configure defaultProxy to pass through that vm.
That's TCP retransmission timing out. It's odd that you are getting different values though.
I'm in the process of troubleshooting an App Service that is using websockets.
It's running on service plan Basic which allows for 350 websockets.
This is the only app on that plan that uses websockets.
The problem is that after abou 20 hours I get 503 responses saying I reached my websocket limit.
The setup right now has 3 clients connecting to the service.
In the process of investigating websocket leakage in my app I would like to track the number of websockets in use.
Is there anywhere, from my app or in Azure portal, where I can see the number of active websocket connections?
Follow up:
I've logged the websocket connections as Amor suggested.
The HTTP part of my app is still working, I can get dynamic results from the app which now reports what websocket connections are active and how many has been created since start.
After restarting the app service and configured one client to reconnect indefinetely.
It worked fine until the "total websocket connections" reached 350. At this time I shut down the client.
The limit should be 350 concurrent connections but it looks like it is 350 in total since start.
Most (at least 340) of these connections were initiated by a single client which disposed each connection before starting a new one, it has been shutdown once the limit was reached.
I've been suggested to upgrade from Basic to Standard since standard doesn't have the artificial limitation. The only reason I can see this work would be if there is a bug in the websocket limitation for the Basic plan.
Update 2
In parallel I've been in contact with Microsoft Developer Support and they noticed what appears to be that the sockets are stuck in IIS whereas not in Kestrel. The cause of this is still being investigated.
Support could show me graphs of the connection usage over time which clearly showed how the limit was reached.
I'll keep this question updated in case there was some error in my code.
I suggest you define a variable to count the connections. If a web socket connection is opened, just increase the number of connections. If a web socket connection is closed, decrease the number of connections. Code below is for your reference.
Count the connections for ASP.NET SignalR.
public class MyHub : Hub
{
private int _connectionCount = 0;
public override Task OnConnected()
{
_connectionCount++;
return base.OnConnected();
}
public override Task OnReconnected()
{
_connectionCount++;
return base.OnReconnected();
}
public override Task OnDisconnected(bool stopCalled)
{
_connectionCount--;
return base.OnDisconnected(stopCalled);
}
}
Count the connections in traditional ASP.NET.
public class WSChatController : ApiController
{
private int _connectionCount = 0;
public HttpResponseMessage Get()
{
if (HttpContext.Current.IsWebSocketRequest)
{
HttpContext.Current.AcceptWebSocketRequest(ProcessWSChat);
}
return new HttpResponseMessage(HttpStatusCode.SwitchingProtocols);
}
private async Task ProcessWSChat(AspNetWebSocketContext context)
{
WebSocket socket = context.WebSocket;
while (true)
{
ArraySegment<byte> buffer = new ArraySegment<byte>(new byte[1024]);
WebSocketReceiveResult result = await socket.ReceiveAsync(
buffer, CancellationToken.None);
if (socket.State == WebSocketState.Open)
{
_connectionCount++;
//Process the request
}
else
{
_connectionCount--;
break;
}
}
}
}
Context
I have a RedisMqServer configured to handle a single message on my ServiceStack web service. The messages on that MQ originate from another application and show up in the .inq with all the correct properties. Everything is on 4.0.38.
My configuration in MyAppHost.cs:
public override void Configure(Container container)
{
var redisFactory = new PooledRedisClientManager(0, "etc:etc");
redisFactory.ConnectTimeout = 5;
redisFactory.IdleTimeOutSecs = 30;
redisFactory.PoolTimeout = 3;
container.Register<IRedisClientsManager>(redisFactory);
//Plugins, Filters, other Registrations omitted
var mqHost = new RedisMqServer(redisFactory, retryCount: 2);
mqHost.DisablePublishingResponses = true;
mqHost.RegisterHandler<CreateVisitor>(ServiceController.ExecuteMessage);
mqHost.Start();
}
And then in Global.asax.cs:
void Application_Start(object sender, EventArgs e)
{
new MyAppHost().Init();
}
Problem
The messages are not consistently handled when I deploy this elsewhere. They wait in the .inq until whenever. Nothing is lost, just delayed for an indeterminate duration.
As of this moment, the only things that come to mind are:
I'm using IIS Express locally, and the server is using IIS.
Application_Start needs to happen before it can handle messages.
I've tried initializing the service by making other API calls over HTTP, before and after queuing messages, with more failure than success. Sometimes the service starts to handle them, but I am unable to identify and thus influence when this happens.
Note
I do have several other console applications and windows services that listen on other MQs and handle messages placed by other applications, and those have always worked flawlessly. This is the first time I've tried this from within an existing web service, however.
Hard to know what the issue from this description (are messages getting lost or just delayed?) but this sounds like it's due to ASP.NET AppDomain recycling in which case you can disable AppDomain recycling or setup up a continuous ping route to hit your ASP.NET Web Application to keep the AppDomain alive.
If the ASP.NET Service is available on the Internet you can use services like https://uptimerobot.com or https://www.pingdom.com to configure it to ping your Service at different intervals (e.g. 5-10 minutes) otherwise if this is an internal Service you can use a Scheduled Task.
I'm building a simple Azure Worker Role to Subscribe to a zeromq Publisher (using NetMQ in the worker) and store messages into Azure Tables.
Everything works fine when I run the worker on my dev machine. Messages come in and are written to the table.
However, when I deploy the worker to Azure something stops working. I can attach to the worker and see that it is stuck on the blocking subscriberSocket.Receive() call. From the point of view of the worker, no messages ever turn up at the subscribing socket.
I've RDP'd on to the worker and using netstat I can see the outgoing connection from the subscribing socket to the remote publisher is established, so it doesn't look like a firewall issue.
From the logs / diagnostic info everything seems to be normal, it's just that no messages are ever received.
Is there some Azure configuration I've missed? Something that would allow outgoing connections but prevent data getting through?
Relevant part of the worker code:
private async Task RunAsync(CancellationToken cancellationToken)
{
Trace.TraceInformation("Running Task.");
using (var eDDNcontext = NetMQContext.Create())
using (var subscriberSocket = eDDNcontext.CreateSubscriberSocket())
{
Trace.TraceInformation("Subscribing to EDDN.");
var endpoint = GetEndpoint("EDDNEndpoint");
subscriberSocket.Connect("tcp://eddn-relay.elite-markets.net:9500");
subscriberSocket.Subscribe(String.Empty);
while (!cancellationToken.IsCancellationRequested)
{
Byte[] rawMessage = subscriberSocket.Receive(); //Azure deployment gets stuck on this blocking call.
if (rawMessage.Length < 3) continue;
using (MemoryStream memoryStream = new MemoryStream(rawMessage))
{
//Read past the first two bytes of the zlib header.
memoryStream.Seek(2, SeekOrigin.Begin);
using (DeflateStream deflateStream = new DeflateStream(memoryStream, CompressionMode.Decompress))
using (StreamReader reader = new StreamReader(deflateStream, Encoding.UTF8))
{
I am trying to get a simple WebSocket server going using SignalR, OWIN and Azure Worker Roles.
WorkerRole.cs:
public class WorkerRole : RoleEntryPoint
{
public override void Run()
{
string url = "http://" + RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["MyEndpoint"].IPEndpoint;
using (WebApp.Start<Startup>(url))
{
Trace.WriteLine(String.Format("Server running on {0}", url));
}
while (true)
{
}
}
/* ... */
}
Startup.cs:
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.MapSignalR();
}
}
MyHub.cs:
public void Send(string name, string message)
{
Clients.All.addMessage(name, message);
}
The Endpoint "MyEndpoint" is defined in the Service as http, public and private port 5001.
After starting the service, it shows up under Azure Compute Emulator as running on 5001. However, if I try to connect to ws://127.0.0.1:5001/signalr (or just ws://127.0.0.1:5001) there is no response. I am using two different web socket clients for this purpose (both are Chrome plugins and they both worked fine using other WebSocket servers).
Questions:
1) Is there anything obviously wrong with my setup?
2) Do I need to use the SignalR JS client libraries to connect to the SignalR server, or should any vanilla client implementing the WebSocket protocol be able to connect?
I know this is a bit of an old post but just in case someone needs it...
1) There are two problems you need to address.
First of all, Start method in:
using (WebApp.Start<Startup>(url))
{
Trace.WriteLine(String.Format("Server running on {0}", url));
}
returns an IDisposable (hence the using(...){} block) means it is immediately disposed after creation since execution continues right passed Trace.Writeline(...) without pause.
It's also a bit tricky running these things under the Azure Compute Emulator for a few reasons, mainly because it remaps ports to avoid collisions. If you open up a command prompt and run
netstat -a
you'll find that you have open ports (listening) looking something like this (in my case I'm using port 81):
TCP 127.0.0.1:82 MyComputer:0 LISTENING
TCP 127.0.0.3:81 MyComputer:0 LISTENING
In the general console ouput of Visual Studio, you'll also most likely see something like
"Windows Azure Tools: Warning: Remapping private port 81 to 82 in role 'MyRoleThingy' to avoid conflict during emulation."
This all means that in order to connect to the server you're hosting using your worker role, you'll have to connect to port 82 instead of 81 (probably 5002 in your case).
2) If you implement the protocol, anything should work I think. Managing an initial connection on the port should always work.