I've got a site which has an export feature. This feature can export parts of the database up to a full database export. This has been optimized a lot but still requires some 90-180 seconds to finish. Debugging and time outs aren't an issue, but live I receive a 504 gateway time out error after about 90 secs. I am guessing that IIS gets tired of waiting for the backend to respond and returns a 504. Is there any way to specify a longer time out, e.g. 5 minutes?
I've got an old executionTimeout setting set to 3600 which doesn't seem to do much any more (I believe it's an IIS <7 setting).
I've also tried this suggestion form another Stackoverflow question:
<configuration>
<system.applicationHost>
<webLimits connectionTimeout="00:01:00"
dynamicIdleThreshold="150"
headerWaitTimeout="00:00:30"
minBytesPerSecond="500"/>
</system.applicationHost>
</configuration>
The above doesn't work, the config file is broken. Is the above supposed to work?
Main question: how/can I increase waiting time in IIS to avoid 504s?
This wasn't an IIS issue. I believe the old way of providing a timeout worked. We've got a reverse proxy with a short timeout, this was changed to a longer timeout which effectively resolved the issue.
Related
We are trying to change the socket timeout in Jira as some of the REST API calls are taking too long to respond due to which we are getting Request Time Out Error.
For changing it, we tried the following but NONE of them worked:
We made changes in the General Configuration settings by following this article.
We followed the following article and changed the JVM_SUPPORT_RECOMMENDED_ARGS parameter to increase the socket time and these are our observations:
When setting the JVM_SUPPORT_RECOMMENDED_ARGS to 20000milliseconds (20sec), we found that it fails for the delay above 20sec; rest it is working fine for any value below it.
When the JVM_SUPPORT_RECOMMENDED_ARGS parameter set to any value between 2min to 14min, the delay above 50sec gives error. For the delay uptill 50sec in project creation, it is working fine.
The snapshot of setenv.sh file, where we made our changes:
Please suggest how to increase the socket time out so that we do not get a Request Time Out for a delay of around 2 min.
Any suggestions would be helpful.
If you use unproxied access to your Jira (i.e. via Tomcat distributed together with Jira), then you will have to change the timeout also in the Tomcat configuration: <jira-install>/conf/server.xml.
There's Tomcat's connector configuration:
<Connector port="8080" connectionTimeout="20000" ...
^^^^^
Notes:
Also feel free to contact official Atlassian Support if you have paid subscription.
Also take a look into logs to find out why project creation takes so much time and times-out (it's not normal, project creation is a matter of a second).
We decided to upgrade our website Asp.net core code from .net5 to .net6, we simply set the 'target framework' of the web application to.net6 from .net5. There were no compilation errors, we gave it a test in our development environment and all seemed well.
There were no code changes at all made, and previously the .net5 application has been running for many months without issue (and before that .net framework 4.8).
When we deployed our app to our live production environment, within a few minutes we noticed a slowdown of external calls (calls to https endpoints, often REST-like), we log any calls that take more than 5 seconds, over the space of a few minutes all calls went from slow to timing out (20 seconds).
We are using System.Net.WebClient for all of our calls, which I understand is now obsolete in .net6, however, I would not expect this to suddenly change behavior, and even so, we attempted to change to HttpClient, the recommended approach, with the same results.
I feel like I must be missing something really fundamental, we just upgraded the target framework and redeployed and now all calls made by WebClient eventually timeout.
It feels like a "running out of resources" issue, in code, due to the slow down then timeout, but I am at a loss to explain what is going on here.
To be clear, we are not doing anything special, just calling about 3 external services via WebClient for each user, and we have maybe 100 users a minute at peak, previously, there have been no timeouts.
Any pointers on what might be causing the timeouts would be greatly appreciated.
I guess time will tell if this is the answer, but we changed all of our calls to use DownloadStringTaskAsync and UploadStringTaskAsync, i.e. all calls from blocking to async await, and after 24hrs, we have not seen the same behaviour in our live environment under full load.
Why a web app using .net 5 core would not have these issues but .net 6 would, is hard to understand. For context, we are not under crazy high load, we are talking a peak of perhaps 150 users per minute, but that is what we are seeing.
Perhaps it was something specific to our set up, but I am writing this to save someone else the pain of trying to debug this issue in the future.
That is suspicious and unexpected. If you have HttpClient repro, can you please post it on GitHub https://github.com/dotnet/runtime/issues? (ideally minimal repro we can run locally for debugging)
If your repro is not transferable to another machine, or requires specific endpoints you can't expose, we may have to guide you through some local debugging ...
-Karel (.NET Networking team)
I have a weird issue that just started popping up for our customers. The portal they've been using for years has started freezing on some of the pages that the user navigates to. I tried restarting the IIS Server, the site within and the Application Pool under which the site is site is running. No difference.
In Chrome Dev Tools I can see that it is always one of these three calls that take time to complete:
When it happens, one of those three calls will report that the request is not finished, like this:
When eventually the call completes, I can see that the Content Download took 3.8 minutes. Not sure whether it is relevant or not, but it is always 3.8 minutes:
Did anyone else encounter a similar situation? Is there a suggestion on how to figure out what is happening all of a sudden that triggers these type of behaviours?
TIA,
Ed
Edit: The resource that fails to load after 3.8 minutes always generates a net::ERR_CONNECTION_RESET error:
Edit2: Thanks to all of you trying to help. A little update: I was able to isolate to problem to an issue with the server not serving some of the files. either *.css or *.js. The setting is that of two identical servers placed behind a load balancer. Apparently, the load balancer software was recently updated and right after that we started having these issues. I am working closely with the IT department of our client, trying to figure out what is the impact of the newer version that seems to have triggered all this drama.
I'm using the check_yum - Plugin in my Icinga-Monitoring-Environment to check if there are security critical updates available. This works quite fine but sometimes I get a " CHECK_NRPE: Socket timeout after xx seconds." while executing the check. Currently my NRPE-Timeout is 30 seconds.
If I re-schedule the check a few times or executing the check directly from my Icinga-Server with a higher nrpe-timeout-value everything works fine, at least after a few executions of the check. All other checks via NRPE are not throwing any errors. So I think there is no general error with my NRPE-config or the plugins I'm using. Is there some explanation for this strange behaviour of the check_yum - plugin? Maybe some caching issues on the monitored servers?
First, be sure you are using the 1.0 version of this check from: https://code.google.com/p/check-yum/downloads/detail?name=check_yum_1.0.0&can=2&q=
The changes I've seen in that version could fix this issue, depending on it's root cause.
Second, if your server(s) are not configured to use all 'local' cache repos, then this check will likely time out before the 30 second deadline. Because: 1> the amount of data from the refresh/update is pretty large and may be taking a long time to download from remote (include RH proper) servers and 2> most of the 'official' update servers tend to go off-line A LOT.
Best solution I've found is to have a cronjob to perform your update check at a set interval (I use weekly) and create a log file containing those security patches the system(s) require. Then use a Nagios check, via a simple shell script, to see if said file has any new items in it.
So, I have a web site that serves videos via a HTTP handler, which is our security layer. Some clients have reported that the videos are not working intermittently. I was finally able to reproduce the issue, and our logging coded reports success in validating the user, then the line:
Response.WriteFile(filename); // Where this is the path to a video of about 32 MB
throws the above exception. I found the actual error by viewing the request and response with Fiddler. But the server has 2 GB of memory free, and the videos started working again an hour or so later ( which probably equates to less people using the server, but nothing was changed on it ). We run two websites on this machine, and the other never has issues like this, but it also doesn't use a layer like this where .NET code is responsible for writing the file. I don't see any settings that allow me to change the available memory, nor has google thrown up anything useful. Any suggestions appreciated.
I should add, I stopped and started and then restarted my site, I've had issues that are solved in the short term by doing this in the past. This did not help.
I just ran into this problem trying to Response.WriteFile a ~170 MB pdf.
In my case, using Response.TransmitFile instead worked; (maybe) because it
Writes the specified file directly to an HTTP response output stream,
without buffering it in memory.