I have 2 apps on server: "Websphere Commerce" and "myapp". While Myapp inits, it needs to receive some data from WC using SOAP, however, until both apps are started, the common http port 9060 isn't listening.
There's a flag:
Enterprise Applications > * > Startup behavior
Startup order
Launch application before server completes startup
It's cleared for both apps. I thought, WAS would first report:
TCP Channel TCP_2 is listening on host * (IPv6) port 9060.
Server server1 open for e-business
then start the apps, but it first starts them, then opens the port.
Then what does this flag do?
Check this page Startup behavior settings
Launch application before server completes startup
Specifies whether the application must initialize fully before the
server starts. The default setting of false indicates that server
startup will not complete until the application starts.
A setting of true informs the product that the application might start
on a background thread and thus server startup might continue without
waiting for the application to start. Thus, the application might
not be ready for use when the application server starts.
So it is other way around, server first ensures that applications are started and then opens port to allow traffic to them.
Related
We found a problem, ASP.NET Core application on some servers randomly restarts every day at random times.
Windows Server 2012 R2 Standard, IIS 8.5.9600.16384
Hosting bundle Microsoft.NETCore.App 2.1.4, Microsoft.AspNetCore.App 2.1.4
Out of process hosting model
Application pool recycling is disabled
In Event Viewer
In Application Section
Application 'MACHINE/WEBROOT/APPHOST/APPLICATIONNAME' started process
'xxx' successfully and is listening on port 'xxx'. (Event ID 1001)
Sent shutdown HTTP message to process '6860' and received http status '202'. (Event ID 1006)
App_offline file 'app_offline.htm' was detected (Event ID 1012)
And in System Section at same time
The TCP/IP NetBIOS Helper service entered the running state. (Event ID 7036)
The TCP/IP NetBIOS Helper service entered the stopped state. (Event ID 7036)
The TCP/IP NetBIOS Helper service was successfully sent a stop control.
The reason specified was: 0x40030011 [Operating System: Network Connectivity (Planned)]
Comment: None (Event ID 7042)
All events happen in 2-3 seconds
It sounds like you have periodicRestart configured on IIS. https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/applicationpools/add/recycling/periodicrestart/ I think the default interval is 29 hours. Disable this setting.
Very strange behavior IIS and AspNetCoreModule when our application node have problems with DHCP when lease time has expired and LAN adapter refreshes DHCP leases.
At this point, the aspnet module starts to see the app_offline.htm file (we have no idea why this is happening) and then immediately restarts the application.
And only servers with this problem, DHCP was turned on.
We specified a static IP address in the adapter settings to solve this problem.
I had a similar problem, where IIS stop the application pool randomly with the event log :
Sent shutdown HTTP message to process with Id '11076' and received http status '202'.
follow by
Application '/LM/W3SVC/82/ROOT/<MyApp>' with physical root 'Z:\wwwroot\<MySite>\<MyApp>\' shut down process with Id '11076' listening on port '42901'
IIS has a IDLE functionality, that stop the application pool when it is idle (no request during a period).
By default, the period is 20 minutes. I see the application pool start on the first request and it is stopped 20 minutes after.
To disable the IDLE, you can specify a interval time to 0 (corresponding to infinity) in the default pool application settings :
I've node application and I use the following guide to debug it which works great
https://codeburst.io/an-easy-way-to-debug-node-js-apps-in-cloud-foundry-22f559d44516
Now I've a bit more complex scenario which one application is spawn other node application which I want to debug (the spawned application ) , in the cf top I see this app PID (of the spawned app) but my question if there is a way to debug it also ? both app running in the same container .
I was able to debug the master app but not the spawned app..., any idea how ?
I was able to ssh the main app, we are using cf 2.98 version
I don't think there's anything CloudFoundry-specific that needs to be done to make this work. The process described at the link you provided is showing how you can launch an application with the node --inspect flag, create an SSH tunnel to the port where node is listening and then attach to it remotely over the SSH tunnel.
If you're spawning subprocesses, I would suggest that you make sure those subprocesses, assuming they're also running Node, have the --inspect=<port> flag passed to them. In this case, you will need to set a port because the default port 9229 used by --inspect is already taken by your main process.
I don't know if your subprocesses are short or long-lived, but you may need to log the inspect port assigned to them somewhere so that you know which port to connect to so that you inspect a specific subprocess.
Hope that helps!
I have a C# console application / Windows sevice that uses the HttpListener stuff to handle requests, IIS is setup to reverse proxy to this via ARR.
My problem is that when I update this application there is a short downtime between the old instance being shut down and the new one being ready.
The approach I'm thinking about would be to add 2 servers to the server farm via local hostnames with 2 ports and on update I'd start the new instance which would listen on the unused port, stop listening for new requests on the old instance and gracefully shut it down (ie process the current requests). Those last 2 steps would be started by the new instance to ensure that it is ready to handle the requests.
Is IIS ARR load balancing smart enough to try the other instance and mark the now shut down one as unavailable without losing any requests until the new one is updated or do I have to add health checks etc (would that again lead to a short downtime period?)
One idea that I believe could work (especially if your IIS is only being used for this purpose) is to leverage the IIS overlapped recycling capabilities that are built-in when you make a configuration change. In this case what you could do is:
start a new instance of your app running listening in a different
port,
edit the configuration in ARR to point to the new port.
IIS should allow any existing requests running in the application pool within the recycling timeout to drain successfully while new requests will be sent to the new application pool.
Maybe if you share a bit more on the configuration you are using in ARR (like a snippet of %windir%\system32\inetsrv\config\applicationHost.config and the webFarms section)
I have azure cloud service worker role running, only 1 role instance
The worker role acts as a TCP server listening on port a port which is configured in the service definition file.
So after the role instance is running, my tcp client program is able to connect to the work role.
But, every time when I reboot the role instance, or publish a new version within the visual studio, i wait the reboot or publish finish, the azure portal says it's status is running, the tcp client program is still not able to connect the server, BUT, without doing nothing, about 10 mins later, it fixed itself, the tcp client is able to connect again.
Where does this 10 min delay come from?
I thought as soon as the role instance's status becomes Running, it should work again.
First, I thought it is because of the Load balancer. But, I remote in the that role instance, and use command line netstat -A , the port is not even listening. So, seems my code for the worker role is not running?
When 10 min later, it is good for connect, I went to remote desktop, and use netstat -A again, now that port is listening.
So, after the reboot/publish, I have to wait for 10 mins to have my worker role code running?
Or I am missing something here?
Hard to say, but the following references should help:
http://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx. This gives you the architecture of the processes running inside your service. When you RDP and netstat shows the port is not listening, what do you see as far as processes? Is WaWorkerHost.exe running?
http://blogs.msdn.com/b/kwill/archive/2013/08/09/windows-azure-paas-compute-diagnostics-data.aspx. This walks through all of the diagnostic data typically used to troubleshoot an issue in an Azure PaaS VM. If you check those logs and event logs do you see anything that stands out between the time when you can't connect and the time that you can?
You can check the Windows Azure event log to see when your OnStart() and Run() methods are started and stopped. If you see that Run() has started but netstat still shows the port as not listening then you know the problem is in your code and you may need to step through with a debugger (you can setup remote debugger so you can use Visual Studio on your desktop to debug the Azure VM - http://blogs.msdn.com/b/cie/archive/2014/01/24/windows-azure-remote-debugging.aspx).
Prologue: I am running windows Server 2008 R2 on a Virtual Machine. This virtual machine image has been happily hosting TeamCity on port 80 for several weeks. This TeamCity server is accessed by others on the network by visiting a url (pcname.domain.com).
The Issue: It seems corporate decided to push some updates to my machine over the weekend. It seems this round of updates decided to install/update IIS. Low and behold, visiting the URL mapped to the TeamCity server actually takes me to the stock IIS7 page. Visiting url/login.html brings me to the TeamCity log-in page.
Attempts: First off, I changed the TeamCity port to 8080 and was able to access it at url:8080 (or localhost:8080). However, it is imperative to me that people can access the server without providing a port... so I change TeamCity server port back to 80 and set off to try and fix this IIS problem.
Since then I have uninstalled IIS7 by removing the role and services from Windows - I am now hosting "0 roles". I have removed every trace of IIS from my PC, but visiting localhost still gives me 404 not found (instead of server not found or just my TeamCity page).
My Question: How do I prevent Windows Server 2008 from trying to host some default crap on port 80 so that my TeamCity server can be seen again?
EDIT: After performing netstat -ano, the only PIDs associated with port 80 are '0' and '4' (system and svchost!)
In windows the usual suspects using port 80 are IIS itself, and maybe the Web Deploy Agent Service if installed (but it could have any other app bound to that port). The PIDs 0 and 4 just tell you that the applciation using that port is running as a service. If you do not need any of this (IIS, web deploy, etc), go to Services and disable them, the port should be free to bind after that.
You can use net sh http show servicestate | findstr HTTP to reach the address and port binding information.
A simple solution (one that I am also using in a production server with multiple apps) is to set up a proxy based on either the domain or the URL path itself (see here how to with nginx).
Hit command, netstat -ano in an elevated command prompt to see what applications are listening on which ports. This command will show you the PID of the process that is listening on port 80. Now, open the Task Manager -> Processes tab. From the View -> Select Columns menu, enable the PID column, and you will see the name of all the processes those are listening on port 80. You can kill the listed tasks. Mostly applications like, World Wide Web Publishing service, IIS Admin Service, Web Deployment Agent Service may use the port 80 in Windows Operating System.