@mksd, found this https://forums.docker.com/t/incredibly-slow-to-create-tables-in-mysql/22557/5
It may be an issue with Docker for Mac… Any chance you could downgrade to 1.12.0 as it is reported for 1.12.1 and above…
@raff … looks like that could indeed be my problem (I’m on 1.12.3). Looking into downgrading it now…
Thanks for your input both. @ssmusoke, did you not run into this issue yourself as well? Or what’s your version of Docker?
Here is how to downgrade Docker back to 1.12.0 (assuming you’re coming from 1.12.3) using Homebrew (so on OS X):
rm -rf /usr/local/Cellar/docker/1.12.3/
cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
git checkout 3330182 docker.rb
brew install docker
This is the commit history of the Docker formula: And the 1.12.0 bottle is commit 3330182.
And if you are using the Docker cask:
brew cask uninstall docker
brew cask install
https://raw.githubusercontent.com/caskroom/homebrew-cask/aad529bcb87bed47280777fc58ca2c7163865f80/Casks/docker.rb
Again aad529b was identified as the commit in the history that would brought up version 1.12.0.
It worked!
Quick findings: It took no less than 1,240 sec to go through the db import:
/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/dump.sql
So please set a fairly high timeout in your next commit(s) for the SDK.
I also got this warning that I don’t remember ever seeing outside of Docker (and it got stuck for a while on this):
WARN - AbstractTableMetaData.getDataTypeFactory(166) |2016-12-16 19:19:56,033| Potential problem found: The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'MySQL' (e.g. some datatypes may not be supported properly). In rare cases you might see this message because the list of supported database products is incomplete (list=[derby]). If so please request a java-class update via the forums.If you are using your own IDataTypeFactory extending DefaultDataTypeFactory, ensure that you override getValidDbProducts() to specify the supported database products.
Overall, the whole process took about 30min. I know that when we have to re-index the db it can take quite long, but probably less than that.
An immediate comment would be that I can see that you have exposed the /modules at the root level, alongside openmrs-server.properties, openmrs.war… etc. Would it be possible to add the /complex_obs folder (since we need it for VDUI)? Or what would you suggest as a method to restore the complex obs files to a Docker OpenMRS instance?
@raff… kudos to you! Thanks also for taking the one to one time on IRC earlier. Very very much appreciated 
Actually this works and is - I believe - good enough:
docker cp /host/path/to/complex_obs openmrs-mydistro:/usr/local/tomcat/.OpenMRS
Where ‘openmrs-mydistro’ is the Tomcat container name.
@maimoonak do you find this thread helpful for the unattended installation of OpenMRS? You could take a look at the installation script whose properties you can read from https://github.com/openmrs/openmrs-core/blob/master/web/src/main/java/org/openmrs/web/filter/initialization/InitializationFilter.java#L314-L364