When the client loses connection an tries to reconnect with the server, I'm receiving this error (with the id of one of my objects). This only happens on the deployed app on heroku. I couldn't reproduce it on localhost.
I can reproduce it manually (only on prod) by quickly calling a succession of Meteor.disconnect() and Meteor.reconnect(). If I wait a couple of seconds between this 2 calls, the error doesn't occur, so I think it's some race condition.
I think it's something I've messed with, as I cannot reproduce this on a sample meteorpad app (same release of Meteor).
I'm using Meteor 1.0.
Any leads?
Heroku doesn't support sticky sessions. See "random page reloading issue" on http://joshowens.me/modulus-vs-heroku-vs-digital-ocean/.
Related
I know that the information that follows is most certainly not enough to solve my problem and I may specify what is needed when and if needed.
The situation is the following. I was programming normally and, as I did, I made a PUT request to my application backend. The browser tab suddenly logged many (like, many) errors concerning different information which I cannot remember due to the fact that it closed itself soon after. Almost at the same time, both VSCode windows I had open and running the backend and frontend of the application closed themselves.
Since then, the backend does not appear to answer any HTTP request made to it. It doesn't get to the point in which the code of the controllers run, for I have put a console.log there and nothing is logged. Similarly, no errors are shown in the console when the request is made. It still connects to an MQTT broker, as it was supposed to.
The Insomnia request loads forever unless I cancel it, and, Insomnia still notices when the connection is reset, giving the
Failure when receiving data from the peer
error.
Lastly, the frontend created a debug.log file in the project's folder that contain 21 lines that read
[0624/203732.834:ERROR:crash_report_database_win.cc(428)] unexpected header
with the only difference being the numbers in the start, and, also created a yarn-error.log, a very long log with a line that caught my eye (because it had the word "Error" in it) that reads, among other things,
Trace: Error: EBUSY: resource busy or locked...
I have no clue what happened or what I should do.
Run the following:
npm install express
In case of TL;DR - I basically need guidance regarding what tools are available to debug requests which are issued to IIS and which stall inside a module.
I have a problem with an old ASP 2.0 app at the moment whereby it will periodically become unavailable and recycling the app pool (horrible as that may be) doesn't bring it back up 100% of the time.
So first of all it presents itself as requests entering the app pool and being trapped in state 'BeginRequest' in RewriteModule.
It is not a specific request which is always the first to experience this issue. The issue cannot be easily recreated either.
Eventually requests join this backlog and when it becomes 70+ deep the app pool fails to respond to pings from WAS and it forcibly recycles. Predictably it doesn't stop on-time and the old app pool is forced to stop. When the new app pool comes up it either works just fine or it instantly experiences the same issue as the outgoing one and requests begin to queue.
In issues like this all the official guidance is understandably focussed around looking at why the RewriteModule may choke.
I have validated my redirections and though complex there are no obvious issues with syntax (XML validates).
Likewise in inetmgr loading up the URL Rewrite Module seems to parse the configs fine and show them visually.
Basic stuff like permissions is all fine.
When the app is working normally I also used Failed Request Tracing/Logging to look at the request pipeline for a sample URL which stalled and I can confirm that there is no circular logic or weird errors presenting - the request seems to be handled just fine. This also showed me how high up the rewritemodule is invoked and from this I really don't see how the issue could be app-related as .NET isn't invoked at this point.
Annoyingly when an app pool is experiencing this issue and I can throw in requests which just stall Failed Request Tracing is no good because you actually need a request to get to the end of it's journey and fail otherwise it refuses to log anything out.
I resorted to taking process dumps of affected w3wp.exe's and running them through DebugDiag. Unfortunately the only thing I see is that threads are open accessing the rewritemodule but precious little about what they are stuck on.
As anyone else would do I've tried to track the start of the issue back to any recently installed patches or code changes but nothing matches. Likewise this is happening on 3x servers otherwise I would try reinstalling the rewritemodule. Other sites on the same server which invoke rewritemodule are unaffected.
Has anyone else experienced issues like this - the net seems to have relatively little info in this case. Perhaps you can recommend further debugging tools or approaches for IIS which I can adapt to this scenario? This is sort of a cry for help from someone more used to Apache/Nginx - sorry for the long post.
We have a secured & authenticated WCF service which cannot use service references. Thus, we provide the interface for the contracts and open client channel manually.
We have found out that as long we open it once, everything works fine. We can call several methods several times. However, if the channel is closed or just set to a new instance, the Login() (which happens to be required for first step prior to using the service), times out.
To make the matters even more mysterious, this only happens on our production server. If I run the same project locally, I am able to login many times as I want. Consuming the methods inside a web browser (even on a code-behind ASPX page) do not have this problem even with the production server. ONLY when it's a .NET client trying to open a client channel against the production server, do we have this problem.
We are not even sure where to start looking. Any advices would be greatly appreciated.
UPDATE:
As per #Rene's suggestion, we turned on logging on both sides. From client's log, there is a record of error which is basically the same timeout error we already got via the exception. Nothing meaningful. On the server's logs, there are records of service methods being invoked successfully even after 2nd login() and from server's POV, the request is served.
Additionally, I discovered that I could not even reproduce this issue on my machine using same test project to reproduce this problem. This reproduces on my developer's machine. I verified that we were at same version of .NET framework and Visual Studio. It has to be surely a client-side problem. What could be it?
In case anyone else is looking for answer, we finally found it -- the issue is due to the need to set on client's side System.Net.ServicePointManager.DefaultConnectionLimit to some higher value. The default value is 2 but in reality this allows only one proxy to be created and be usable. Setting it to 3 would allow 2 proxies to be created & be used.
We have an ASP.Net web application on IIS7 that is used to upload Excel files and then load them into a SQL database by running jobs on the SQL server. The app will wait until the job completes then show the user a message. Due to some larger files being used the app is throwing the error below.
Network Error (tcp_error)
A communication error occurred: "" The Web Server may be down, too
busy, or experiencing other problems preventing it from responding to
requests. You may wish to try again at a later time. For assistance,
contact your network support team.
The app uses an asp:View to progress from various steps. I have tried to bump the session timeout and httpRuntime executionTimeout values to account for how long the job takes to run but it does not appear to have any effect. I know the job completes but the app isn't showing that feedback to the user. I think the error is thrown as the app hits the logic to display the user the view showing all the final messages.
I can only guess that a) there is another setting I'm not aware of for timeout, b) another config file setting is overruling my web config setting for the app, or c) the asp:View is counting all the various steps as one long process and not reseting the "clock" as each step is completed.
As I said, the file upload fine, and the job completes fine, the app just can't advance to that last step where it shows the user the view upon the end. Any ideas on what I can look for to fix this issue? My only other option would be to rewrite the app to not wait for the job to finish and handle notifying the user some other way.
Update 1
After further testing it appears the error is from the ASP.Net custom code we created that does a SQL bulk copy and not the running of the SQL job. The current test runs around 220 seconds testing locally but causes a timeout on a test server.
Update 2
After more research I'm inclinded to think user pevgeniev is correct and this is just a limiting factor of the browser. The only thing that prevents me from marking this as answered is I don't know why file uploads don't appear to have the same issue.
If you're getting this error in the browser, than the timeout is on the client side, and there isn't much you could do server side. As you've suggested, you could rewrite the app, so that it polls for the result from the client, rather than expecting to finish the task in a single request.
I've created a Web Service which is accessed by 3 other websites. In 1 instance, after user entered some data and click a submit button it goes off and does it's thing and return true or false.
The problem is when i click submit initially (after a period of inactivity) i get the error
"The remote name could not be resolved: (mydomainname.goes.here)"
However, if i clicked the submit button immediately after, it works fine, and will work again until another period of inactivity.
Any suggestions where to begin.
EDIT: New data - I was ready to accept it being a DNS issue at the server site since i tested it from 2 locations (home and office with different ISPs) and the problem seemed consistent, however at the last minute i tried it from my sprint cellular data connection and never has this issue. The web service responds and works well everytime i try it here, regardless of the time that has elapsed between trials. - So i'm doubtful that it's DNS issue again.
The remote name could not be resolved
Something wrong with your DNS/proxy configuration
I've run into a similar problem before when calling web services on Apache from a .NET CF client. Try turning KeepAlive off on your web service client, sounds like a very similar pattern compared with what I was seeing. The web service call would work on the first try, fail if there was an interval of around 10 seconds between calls, and work every time if there was a 1 second interval. I think it was a problem with the Apache configuration.