Move wait-for-postgres.sh to Java

[steven-sheehy]

• Moved the logic in wait-for-postgresh.sh to DatabaseUtilities.openDatabase(). Moving it to code allows both docker and non-docker deployments to startup java processes before postgresql and not immediately crash.
• Removed wait-for-postgres.sh and any place that references it
• Removed custom startup scripts for each microservice as it was only needed due to needing to invoke wait-for-postgres.sh.
• All java microservices now use adoptopenjdk:11-jre-hotspot instead of manually installing jre since they don't need pgclient. Smaller image, smaller attack surface, simpler.
• rest-api doesn't need wait-for-postgres.sh as it doesn't crash on startup if pg down like java.
• Simplified docker mvn build to not use script and dockerfile
• Removed use of postgresInit.sql in docker deployments as it was failing with psql:/docker-entrypoint-initdb.d/postgresInit.sql:32: \connect: FATAL: database "hederamirror" does not exist

Would appreciate a quick test run by someone else to make sure I didn't mess anything up.

[gregscullard]

@steven-sheehy in various places, I've got this code

if (Utility.checkStopFile()) {
	log.info(MARKER, "Stop file found, stopping.");
	break;
}			

such that if a file called stop is found in the runtime folder for the mirror-node, processes shut down cleanly. Seeing DatabaseUtilities.openDatabase() is a potentially infinite loop, I sense we should have the same check there.

[steven-sheehy]

@gregscullard I added the stop file check to the loop.

[gregscullard]

@steven-sheehy I've tested this PR and it looks good. I've made a few changes to fix bugs I introduced in the SQL migration scripts.
It won't pass CI though and I can't find out why at the moment.
Local mvn install works ok

[steven-sheehy]

@gregscullard I think the build is failing because I've yet to merge the new circleci config from master. I can do so soon, but it might be better if you submit your new commits as a separate PR first. The reason is because you and Calvin seem to be making contradictory changes back and forth to these SQL stored procedures and might need to sync up first and ensure you're on the same page.

[gregscullard]

Ok. Will tidy up tomorrow Envoyé depuis mon iPhone/Sent from my iPhone

…

Le 18 août 2019 à 23:03, Steven Sheehy ***@***.***> a écrit : @gregscullard I think the build is failing because I've yet to merge the new circleci config from master. I can do so soon, but it might be better if you submit your new commits as a separate PR first. The reason is because you and Calvin seem to be making contradictory changes back and forth to these SQL stored procedures and might need to sync up first and ensure you're on the same page. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[steven-sheehy]

Cool, I think your approach is probably correct and Calvin is just maybe not running flyway correctly. I have an upcoming PR to move flyway to Java code to make it run automatically.

[gregscullard]

Part of the problem with the sql scripts is that we are targeting two different Postgres versions (11.6 on docker and 9.x in production). 9.x doesn’t support “create or replace”. Not sure if it supports “drop if not exists”. Either way, when creating a proc/function first time, there is no need to drop (the drops are left overs from the development/test process and should not have been there in the first place). When we fix an existing procedure or function we know we can drop and re-create. Flyway enforces that every migration applies to a known state so we should be able to avoid those issues in the future. Envoyé depuis mon iPhone/Sent from my iPhone

…

Le 19 août 2019 à 01:09, Steven Sheehy ***@***.***> a écrit : Cool, I think your approach is probably correct and Calvin is just maybe not running flyway correctly. I have an upcoming PR to move flyway to Java code to make it run automatically. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.