I have a django web app running via gunicorn and nginx is serving as a reverse proxy.
The web app provides few API calls. One of the API call (let's say GET /users) is giving me a Connection timed out error. All other HTTP calls work fine always.
If i restart the Django/gunicorn process, GET /users works fine for a couple of hours and then starts giving same problem again.
GET /users is simply parsing query params and pushing some data into rabbitmq. It's not the issue with rabbitmq connection/channel, that i am positive.
Anyone has any idea what could be wrong?
I have tried all available solutions on stackoverflow (including modifying proxy* headers in nginx, changing gunicorn timing and what not.)
Related
I am running a Django project with react redux (trying to implement authentication system) and the very weird thing i observed that my site is rendering properly when i use localhost:8000 or http://127.0.0.1:8000.
But when i m trying to login/signup (ie trying to send post request) then it working only when i use localhost:8000, and giving some error when using http://127.0.0.1:8000.
One of the error when using http://127.0.0.1:8000 is shown below.
However i have seen this and found localhost will often resolve to ::1, the IPv6 loopback address. But i am getting is it related to this or not ?
And whether localhost:8000 and http://127.0.0.1:8000 is same or not ?
Please try to answer in simple words because I have not much knowledge of internet protocol or networking.
This problem is because of CORS. You have to enable from outside your application.
This happens because django apps and generally all frameworks blocks requests outside your address.
You can read more about CORS here
I have a django channels project. I'm currently using the
ASGI/Channels version 2.1.7 development server
When I start up the server, and connect to it with a browser, the HTTP requests start getting served right away, and the HTML page loads in the browser. As soon as the page loads, it tries to establish a websocket connection, which fails.
I'm using reconnecting-websocket library, so it keeps trying, and failing. I can see it failing because there are messages in the firefox console that say the connection attempt failed. Refreshing the page doesn't help. After about 30-45 seconds, it starts working. At that point, as long as I keep the development server running, I have zero issues with my websockets - they always connect right away when I load a page that uses them.
The problem doesn't always appear (sometimes it works right away), but when it doesn't, it's always the first 30-45 seconds after starting the development server. It's very annoying to have to wait 30-45 seconds during development every time I need to restart the dev server.
A tcpdump on the server shows websocket requests coming in with a proper destination port, but getting a TCP RST. The failed connection attempts don't show up in the development server logs at all (the ones printed to the screen). It almost seems like Linux is dropping the requests because the socket is busy or something. It's strange though that HTTP requests don't get dropped, but websocket requests do, even though both use the same port.
Anyone have any ideas? Anyone come across this? Any extra debugging I can enable, either on Linux, or on the dev server?
Edit: Using nginx and daphne for deployment, I have no problems. As soon as systemd starts up both nginx and daphne, which only takes about 3 seconds on my raspberry pi, I can load the page, and the web sockets connect perfectly. Only the dev server has issues.
I deployed my rails project on heroku but I am facing timeout error on heroku. I am using puma server on heroku. My project is about scraping web data using URL. I also tried webrick & unicorn server. Can anybody suggest me the solution for this problem?
Your question is lacking information about what is causing the Timeout error. As you are fetching data from other web pages, it's likely the timeout is caused by a not responding HTTP URL.
In this case, the web server you are using may be irrelevant. In fact, Heroku imposes a request timeout of 30 seconds. If your app doesn't return a response within 30 seconds, the request is terminated by Heroku. It doesn't really matter which web server you are using.
In order to solve this problem you have to
set a timeout in your code (you can use the Timeout library) to make sure that no external HTTP request takes more than a certain period of time, which must be lower than the Heroku timeout.
you may also want to move lon-running tasks away from the context of a request into async jobs that are not subject to the request timeout in Heroku. However, in order to do that you will require a background job system such as Sidekiq or Resque.
The problem with my Django App is that the Google Oath2 Redirect takes 2 minutes to login. I am using uwsgi + nginx on the server-side. It only happens on the login request.I had earlier tried using Nginx + Gunicorn,
nginx error logs said something about Connection reset by peer(104).But i don't think the error is with nginx. It still doesn't work even if I disable nginx.
The stack trace when running the server on django dev server:
The Google Oauth2 Takes 2.1 minutes of time.
Any Suggestions? Pointers?
I had the same issue on a server 2 weeks ago. In my case, the server was resolving all URLs using ipv6. It would take 2 minutes to resolve each URL. So, I just turned off ipv6.
Try disabling it.
I've got django running on a dev. box that I'd like to be able to make requests to from another dev. box on my LAN. I'm getting no response at all though, even though I can ping just fine, no firewalls are operating, etc.
Is there a setting in Django somewhere that prevents it from responding to remote requests by default?
Thanks
Are you binding the Django server to 127.0.0.1 perchance? Or are you binding to the IP addres assigned to an interface that is reachable by the other computer?
To bind the server to another address look at using python manage.py runserver <ip address>:<port> as answered in this StackOverflow question: google code + temp server?
Also see the manage.py documentation from Django.
Do note that there is going to be a performance impact, the dev server is not meant for concurrent access and will perform poorly if multiple people are browsing at the same time..