gaurav
commented
5 years ago I tried running JPhyloRef on Heroku last week: it looks like it won't work for us after all since their dynos are limited to 512MB of memory; running JPhyloRef on a relatively small ontology results in an out-of-memory error.
I met with UF's Research Computing (UFRC) last week, and it looks like the best way to get JPhyloRef hosted with them would be to write a small Node.js HTTP server application hosted on UFRC's web hosting infrastructure (PubApps) that would accept input jobs as JSON files, start JPhyloRef on a compute node on the UFRC system, and return a token to the Authoring Tool. The Authoring Tool would then have to poll the server app for the reasoning results. This approach would require finding or writing the job manager HTTP server application and modifying JPhyloRef so that it can report on phyloreference resolution on the command line. We would have to think about setting up API keys or other systems for preventing overloading of this system.
I've confirmed that JPhyloRef runs fine on the UFRC's high-performance computing system. Unfortunately, PubApps uses an older version of Java that the OWLAPI library we use doesn't support, so I've put in a request for them to upgrade it. Once that happens, I should be able to test the feasibility of this approach pretty quickly.
I currently run JPhyloRef locally when demonstrating the Curation Tool. If we'd like other curators to be able to reason with it, we will need to run JPhyloRef on a server somewhere. This issue will track trying out trying out different options to achieve this.
Heroku might be an option: it's free for limited use and has support for Java. If increased computing resources are needed, they are charged by the second, which would work well here, as reasoning will likely only be used for a few minutes a day.