Retry DOI registration on failure

[pdurbin]

If the DOI service is down for any reason, we should retry DOI registration periodically until it succeeds.

[sekmiller]

First step (saving a success time when registration occurs) complete.

[sekmiller]

Added a manual process for user to retry registration prior to publishing. Does this eliminate the need for a timer job?

[eaquigley]

I feel like we should still have a timer job and have the DOI try to be registered so the register DOI button can go away. In that case, the user should receive a notification that the DOI was successfully registered (only if it is a DOI that was not able to be registered at first). Moving to 4.1 though.

[pdurbin]

Back in November 2014 I opened this issue because I wanted to explore the notion of what to do generally when services we are dependent on fail or are temporarily down. These included:

• EZID/DataCite DOI (this issue)
• Solr (Solr: load balancing, fault tolerance, and high availability #2322)
• SMTP server
• probably others I'm forgetting. Dropbox probably has a good uptime.

Fast forward to 2017 and I'm worried about new components being temporarily down:

• Geoconnect/WorldMap (Geoconnect: provide heartbeat link to allow service monitoring of geoconnect and worldmap #2251)
• Data Capture Module (Data Capture Module (rsync support) #3145)
• probably others I'm forgetting (Shibboleth IdPs? OAuth providers?)

Services fail. They're sometimes down. (I still dream of the status page we talked about in #131.) I still wonder if we can solve this problem in a general way, perhaps by introducing a messaging queue like RabbitMQ or whatever. That said, this issue is about DOI services being down and we have a one off solution for that so I'm closing this issue. If anyone wants to talk messaging queues, please email https://groups.google.com/forum/#!forum/dataverse-dev or ping me at http://chat.dataverse.org .