At random points in development, hot reload stops working on a Cookiecutter Django application. It happened to me 3 times in different projects, at seemingly random points. There's been no changes to the initial Dockerfile and local.yml script that is used to launch the application. I have tried rebooting docker engine and pruning the entire system but it doesn't affect the problem. What might I be missing?
Related
I'm looking for some suggestions on how I could manage external dependencies when I want to run my Play framework based app locally.
I have a Play based application that connects to a database to look up application data. In order to run this against a specific environment, it is not a problem, but what if say I want to run this locally? With the current setup, if there is no database available, my app would just not start! I mean, without a database running my application also has no meaning as I could not do anything without data!
I'm using MongoDB as my database, so I see the following possibilities to enable running my application locally!
Use in memory mode from MongoDB
Use some sort of docker container to run a MongoDB instance locally
Is there any other possibility that is worth exploring?
We are building a SaaS application. I don't have (for now - for this app) high demands on availability. It's mostly going to be used in a specific time zone and for business purposes only, so scheduled restarting at 3 in the morning shouldn't be a problem at all.
It is an ASP.NET application running in mono with the fastcgi server. Each customer will have - due to security reasons - his own application deployed. This is going to be done using docker containers, with an Nginx server in the front, to distribute the requests based on URL. The possible ways how to deploy it are for me:
Create a docker image with the fcgi server only and run the code from a mount point
Create a docker image with the fcgi server and the code
pros for 1. would seem
It's easier to update the code, since the docker containers can keep running
Configuration can be bundled with the code
I could easily (if I ever wanted to) add minor changes for specific clients
pros for 2. would seem
everything is in an image, no need to mess around with additional files, just pull it and run it
cons for 1.
a lot of folders for a lot of customers additionally to the running containers
cons for 2.
Configuration can't be in the image (or can it? - should i create specific images per customer with their configuration?) => still additional files for each customer
Updating a container is harder since I need to restart it - but not a big deal, as stated in the beginning
For now - the first year - the number of customers will be low and when the demand is low, any solution is good enough. I'm looking rather at - what is going to work with >100 customers.
Also for future I want to set up CI for this project, so we wouldn't need to update all customers instances manually. Docker images can have automated builds but not sure that will be enough.
My concerns are basically - which solution is less messier, maybe easier to automate?
I couldn't find any best practices with docker which cover a similar scenario.
It's likely that your application's dependencies are going to be dependent on the code, so you'll still have to sometimes rebuild the images and restart the containers (whenever you add a new dependency).
This means you would have two upgrade workflows:
One where you update just the code (when there are no dependency changes)
One where you update the images too, and restart the containers (when there are dependency changes)
This is most likely undesirable, because it's difficult to automate.
So, I would recommend bundling the code on the image.
You should definitely make sure that your application's configuration can be stored somewhere else, though (e.g. on a volume, or accessed through through environment variables).
Ultimately, Docker is a platform to package, deploy and run applications, so packaging the application (i.e. bundling the code on the image) seems to be the better way to use it.
I have ZAP installed on a build server (Windows 2008 R2) and on my Windows 7 desktop, and Zap only occasionally starts. I click on the program and my cursor shows it is waiting for a second or 2 and then nothing. Attempting to run from the command line will also not show any signs of running.
Then just out of the blue the program may launch.
Is it possible it just takes forever to start. I left my computer running and the next day when I came to work there was the UI.
I get the same results if I try to run the program in the headless state. with the -daemon flag. it never starts, it never shows up in the task manager, as an application or a process
thanks Noel
Turns out there were 2 issues. The first was that the tool was taking 4-5 minutes to start (I timed it several times at around 4m 30s). I did not have the patience to wait, so I would try to start it again. Attempting to start the application when one had started, but no UI was showing invariable caused the application to hang.
Secondly if you start it as a headless application there is no way to stop it. So if you have it headless and then try to start the application it will cause it to hang. THe easiest way to tell if it is running is to follow the log information being written out as suggested by Psiion above in his link.
To kill the process, look in the task manager for the java process and kill it.
Just in case anyone stumbles across this post, my problem was I didn't have Java installed. I had removed it a few months ago due to security considerations.
You can stop your browsesr using Java easily by using the Java control panel http://www.java.com/en/download/help/disable_browser.xml
I was facing a similar issue, the ZAP tool was working fine on my local machine but was displaying erratic behavior on the Virtual Machine. I tried all the previously mentioned suggestions but none of them could mitigate the issue. Upon checking the log files i found out that the HSQLDB files were being locked even after closing the tool or even if the tool did not start. I eventually figured out that the difference between the 2 environments was just the operating system. My local had Windows 10 pro while the VM had Windows 10 enterprise. So in case if any one else is facing similar, kindly check the operating system.
Is it possible to keep the cache 'loaded' between recompiles?
Using auto-compile mode (play ~run) it calls out to several external APIs to build the response. If I am just tweaking code it is a pain to have to wait to rebuild the whole page every time.
That's the nature of development mode. The server is restarted for every recompile, and the EhCachePlugin is reinitialized. In production however, you shouldn't be using the EhCachePlugin anyway, as it not designed for a distributed environment (since each instance has it's own local cache).
I use the Play2-Memcached plugin for my production servers, and after a lot of similar frustration, I just decided to install memcached on my local machine and use that in development mode as well. I'm only kicking myself for not doing it sooner. It also comes with the added bonus of being able to flushall from the command line.
We do have problems with GWT hosted mode running in Eclipse Ganymede (Windwos XP 3GB RAM). When we start our application in hosted mode it takes very long to start and also the transactions once the application is started are taking minutes to react. It seems as if it takes very long to communicate between Javascript and server.
The processor shows almost no load during this time. Even compiling and starting from an external browser does not help.
Strange is that we do have two other computers (one Windows XP one Linux) with exact the same setup where the hosted mode is working at normal speed without any problems for the same application.
Do yourself a favour, move to GWT 2.0 (currently in RC2) and take advantage of Out Of Process Hosted Mode (OOPHM), which lets you debug straight in the browser, and is lightning fast!
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Try removing all breakpoints. It helped me in such a scenario. Apparently if you place breakpoints in critical points in the program, it can cause everything to grind to nearly a halt in hosted mode.
I second the suggestion to switch to GWT 2. Please note, however, that with GWT 2, hosted mode is very slow in Chrome. I recently switched from 1.7 to 2.0 and found hosted mode to be very slow ... until I switched to Firefox. Reason for this is that Chrome's process model is not benificial to OOPHM, at least now.
A few ideas:
Does the slow Windows box have a heavily fragmented hard-drive?
Is it a specific database query that's taking a long time once the application is running, or are all interactions slow?
Are the project files on a local filesystem?
Is the database on a local filesystem?
If so, does it have the same size data set as the other machines?
If not, are they on different subnets or have different bandwidth available?