I am experiencing next issue:
I have an AspNetCore website that is hosted on Windows Server 2012 IIS 2019.
I am running automated tests(Selenium, Chrome webdriver) for this website from any another server or PC and sometimes(not every time) after about 4 minutes i am getting Connection Timeout Error.
I am getting this error through Chrome Webdriver, Chrome, but website is accessible through any another PC/Server or even IE on the same server.
This continues for 5 to 15 minutes and after it is back again, i can access the website, i can run the tests.
Looks like something is blocking IP/Web browser from IIS.
I am running tests in parallel(4 threads).
I am running the same kind of tests for another website(which is not Core, just regular .Net Framework) and never had such issue with it.
I've checked DNS resolution - everything is fine, am getting the same error even with it hardcoded in hosts
I've disabled server firewall at all - did not work
There is no additional Antivirus protection except Windows Defender
There is no AVG set up on the server
I've tried different Servers, PCs and Chrome versions - still the same error happens from time to time.
Windows Event Log has nothing that can be linked to this issue.
Any help is extremely appreciated.
Related
I've been working on a web app (front Angular, back Node/Express/Mongo) for a few months now.
I run Angular on localhost:4200 and Node on localhost:3000
Some people in our team are running the backend in a VM that runs on their computers.
So that the app works in both cases we've edited the windows hosts file to make the app point to the correct place (either the VM or the back on the local machine)
127.0.0.1 mysite
Developers using the VM changed 127.0.0.1 with their VM's IP.
Everything worked smoothly.
A few days ago, our company installed bitlocker on every PC and I believe it caused our setup to break for everyone not using the VM (which is not subject to bitlocker)
People working on localhost started receiving from the front app:
OPTIONS http://mysite:3000/auth/login 426 (Upgrade
Required)
The requests are not even hitting the Node server. Looks like they're redirected to a websocket server?
If I change the requests to target localhost:3000 the app works again but we lose the setup for people working on the VM. (thus committing code becomes annoying if we need to change the base url each time)
I could make an environment for each case but it's not clean and I'd like to know why it suddenly broke.
Try changing the port from 3000 to something else.
I just ran into this issue when a coworker tried running an express app we've been building on a Windows machine for the first time, as opposed to an EC2 instance. I've been using a Mac during development.
The issue seemed to be that 0.0.0.0:3000 was already mapped on company Windows machines. If you run netstat -an in a command prompt you may see it in use already.
hello mate this usually happens due to protocol mismatch between the PC and server.TLS 1.0 and 1.1 were permanently deprecated on June 4 2018. I suspect you’re using something that still uses and old version of TLS.
I have a WebApp that uploads files to a server, but it is not working in a Google VM with Windows Server 2016 and IIS 10 to files larger than 1MB. It works on others servers with IIS8.5 and WS 2012. When I try to upload, it takes a lot of time, returns a success message, but the file does not go to the folder on the server.
That problem does not occours when I access my webapp from the server itself or another Google VM. It looks like a firewall problem, but I do not found anything different there.
There is some different configuration on WS 2016 or IIS 10 that explains Why it is happening?
I found a VPN that had been disabled, but still blocking the connections. I just remove the VPN and all start to work.
We have been using servicestack version 3.8.5.0 for a few years.
We noticed an occasional error where one of the web services returns 404. This service is part of an assembly where the other webs services all work.
This service has not been modified for a number of years and if we restart IIS the service works as expected.
Any ideas where to look on what might have caused the 'registration' to fail?
Edit:
Just found that this issue happens consistently on rebooting the server. So if I restarted IIS a number of times and I do not see the issue. However on rebooting our server, the issue appeared.
I have Classic ASP web site hosted on IIS 6.0 (It's a production server). It stops serving pages intermittently say for every 1 week or 10 days. after IISRESET again it works fine.
Verified IIS web server logs and there were no request hits found from the logs.
Verfieid HTTPError logs. Nothing found abnormal.
We already configured Application pooling to improve the performance for the website and recycling the worker process every 24 hrs.But, didn't help us much.
Could you please advise me in resolving the issue and what is causing this issue.
We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.