Rather confused here. From my local development machine (OSX), I can't get a dead simple cfhttp call to work (no ssl or anything). These work on my production machine. Both environments should be identical (docker).
On the dev machine, I have tried several different domains/urls:
Lucee version: 4.5.2.018, Apache Tomcat/8.0.28
<cfhttp url="http://www.learncfinaweek.com" method="get"></cfhttp>
<cfdump var="#cfhttp#"><cfabort>
Any thoughts?
Sheesh, after struggling with this for an hour I eventually restarted the docker-machine with docker-machine restart default, restarted the containers, and cfhttp started working again.
As far as why it started happening in the first place, I'm not sure.
Related
I got the err_connection_refused when trying to accessing django running on wsl2 (http://localhost:8000) from Windows but when I use curl http://localhost:8000 from Windows terminal bash, it's working fine. I have tried to add a new firewall inbound rule for port 8000 but it's still not working. Is there anything else I need to take care of.
Thanks a lot
Seems like a forwarding problem. WSL2's interface is NAT'd, whereas WSL1 was bridged by default. WSL seems to do some "auto-forwarding" of ports, but only on localhost. However, sometimes this auto-forwarding mechanism seems to "break down". The main culprit seems to be hibernation or Windows Fast Startup (which are both closely-related features).
Does the problem resolve if you do a wsl --shutdown and then restart the WSL2 session? If so, try disabling Windows' Fast Startup. I already had Fast Startup disabled due to a different (non-WSL issue) on my system, so that could be related to why I am not able to reproduce.
Along the same lines, do you Hibernate instead of powering off? In that case, a wsl --shutdown might resolve as well.
For future readers, note that the above two points seem to resolve the issue for most people who have upvoted and responded in the comments. However, if that does not work for you, the following were my original "additional suggestions":
For some additional ideas, see this github issue. There are some suggestions on services that might be needed. (Side question - Are you running Windows Home or Professional?)
Is there any chance that your Windows hosts file (e.g. c:\windows\system32\drivers\etc\hosts) points localhost to an IP other than 127.0.0.1? If I attempt to access via my local Windows IP address, rather than 127.0.0.1 or localhost, I get an ERR_CONNECTION_REFUSED as well.
Since you were looking at the firewall rules, maybe look at a forwarding rule instead of just an inbound allow?
If all else fails, try exporting/backing up the WSL2 session (see wsl --export), then import it in as a new WSL1 session. See if it works there.
On my WSL2/Ubuntu 20.04 system, I attempted to reproduce (but haven't been able to yet) with the following steps:
mkdir -p ~/src/dj-test
cd ~/src/dj-test
python3 -m venv dj
source dj/bin/activate
pip install Django
django-admin startproject config .
python manage.py runserver
(although I used activate.fish since I'm running the fish shell)
From Vivaldi web browser in Windows, accessed localhost:8000, which returned "The install worked successfully! Congratulations! ..."
curl under Powershell Core worked as well.
We have an app that works perfectly fine on production but very slow on the dev machine.
Django==2.2.4
I'm using Ubuntu 20.04 but other devs are using macOS and even Windows.
Our production server is a very small compared to the dev laptops (it works very slow on every dev environment, we are 5 developers).
The app makes several request since it's a Single Page application that uses Django Rest Framework and React.js in the front-end.
We have tried different databases locally (currently postgresql, tried MySQL and sqlite3), using docker, no docker, but it does not change the performance.
Each individual request takes a few seconds to execute, but when they go all toghether the thing gets very slow. As more request are executed, the performance starts to drop.
It takes the app between 2/3 minutes to load in the dev environment and in any production or staging environment it takes little above 10 seconds.
Also tried disabling DEBUG in the back and front-end, nothing changes.
It is my opinion that one of the causes is that the dev server is single thread and it does not process a request until the previous is finished.
This makes the dev environemnt very hard to work with.
I've seen alternatives (plugins) to make the dev server multi-thread but those solutions do not work with the latests versions of django.
What alternatives could we try to improve this?
Looks like posting this question helped me think in an alternative. Using gunicorn in the dev environment really helps.
Installed it with
pip install gunicorn
And then execute it using this:
venv/bin/gunicorn be-app.wsgi --access-logfile - --workers 2 --bind localhost:8000
Of course if I want to access the static and media files I'll have to set up a local nginx but it's not a big deal
I created a django (1.8+) project some time ago, and it's weird that it works well with runserver, but it's not working with gunicorn (requests never end, nothing is received using curl or any browser to test my server). The funny fact is that it worked until recently (I'm in an AWS/AmazonLinux server; never changed the server image).
Since this timeout really annoyed me (and still does) I checked the project, opened a python interactive interpreter inside my virtualenv, and tried:
from my_project.wsgi import application
inside the appropiate folder (so this statement does not raise ImportError). But that single line took a lot (at least 10 seconds) to execute.
I think that is the reason why is gunicorn not working.
Is there any well-known reason this could happen? How can I debug further?
Edit My gunicorn command: gunicorn trescloud_landing.wsgi:application --daemon --bind=127.0.0.1:8888 --pid=/opt/webapps/pid/landing-pages.pid --access-logfile=/opt/webapps/log/landing-pages.access.log --error-logfile=/opt/webapps/log/landing-pages.error.log
Edit 2 Changed --timeout=600 (yes, 10 minutes) and gunicorn worked. But it is still troublesome to me that the server has a somehow low wsgi bootstrap
Hey I use installed bitnami django 1.3.0,
but whenever I add changes to urls.py or views.py in my system due to some error. The error won't disappear after refresh.
I have to restart my bitnami Service, "stop" and then "start" it, which is time consuming, I feel like I'm coding C# apps in visual studio. Sometimes even that doesn't work, I have to sometimes restart my computer and then I suddenly realize "oh wow, the error is solved now!"
Any solution to this? Why does everything require a runserver / restart?
You can use Apache for deploy your application in production but use the Django server for development. You will need to configure your application for being served by apache later (modifying the settings.py and the apache configuration file) but during the development you won't need to restart the server for every change.
Everything requires a restart because of the way that the python process operates. It does not reload the file when it's changed (outside of runserver..which is an anomaly, and just there for convenience)
Python execution isn't like PHP execution in that way, and your code isn't dynamically loaded on every page refresh, it's loaded on every server restart.
Hope that helps.
I develop web applications using Django on Mac OSX 10.6. I use Django's built in local development server which I run on my computer's IP (such as: http://192.168.0.11:8001/). I test my applications in Firefox, Safari and Chrome and all display fine. I use Sun's VirtualBox with 3 different instances of Windows XP that have IE6, IE7 and IE8 on them.
For whatever reason, these sometimes just don't display the Django sites. They come up with 'The page cannot be displayed'. Eight times out of ten, they display fine and function normally but for no reason at all they won't display. Sometimes restarting Django's local development server from the Terminal will fix the problem, sometimes it won't.
Is there some sort of VirtualBox settings or Django settings that I need to set to ensure smooth operation of this? Am I overlooking something? Has anyone else had these problems?
By default the dev server binds to localhost. to run it on all interfaces use ./manage.py runserver 0.0.0.0:8000
I found the best way to do this is using the normal localhost:8000 or localhost:8001 (any port you need, especially if running multiple Django projects at the same time) in the Mac Terminal.
Then in VirtualBox with Windows, using the ipconfig command in the Command Prompt to find out the IP settings. Grab the Default Gateway (mine was 10.0.2.2 for example) then, in the browser, use this as the address to get to your Django project along with the original port setting that was set in the terminal. So in this case: http://10.0.2.2:8000/
I've been running it like this now for almost a week and it seems to of stopped the problems I was getting before totally. I couldn't really tell you why though!