You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make a small tool or script that creates a static component registry dump that mimics the actual registry in that it contains the following pages at the expected locations:
/rest/registry/profiles
/rest/registry/profiles/{id}
/rest/registry/profiles/{id}/xml
/rest/registry/profiles/{id}/xsd
/rest/registry/components
/rest/registry/components/{id}
/rest/registry/components/{id}/xml
/rest/registry/components/{id}/xsd
For all non-deleted ids. For non-public ids, maybe best to only allow /xsd and /xml.
Also create a notification page at:
/ + /index.html + /index.jsp
It can be used as a drop-in replacement by serving the static files during maintenance to the actual component registry or its host. This can be done either on the same server by reconfiguring the HTTP server, or on another host combined with an update of the DNS entry in case of maintenance that makes the host unavailable (e.g. maintenance at the hosting provider).
We could even perform this at regular intervals and host a fallback 'shadow component registry' that can be switched on when needed (even automatically).
The text was updated successfully, but these errors were encountered:
twagoo
changed the title
Static registry for maintenance
Static registry as maintenance fallback
Aug 8, 2016
twagoo
changed the title
Static registry as maintenance fallback
Static registry mirror as maintenance fallback
Aug 8, 2016
twagoo
changed the title
Static registry mirror as maintenance fallback
Static registry mirror to provide fallback during maintenance
Aug 8, 2016
twagoo
changed the title
Static registry mirror to provide fallback during maintenance
Static registry mirror to provide fallback during downtime
Aug 8, 2016
Possibly an (application agnostic!) solution can be made using a web cache (like squid) that always runs transparently (with limited or no actual caching) in front of the application and can be changed into an 'aggressive caching mode' (with some way of initialising the cache with the URLs of all known expanded specifications and XSDs) during maintenance.
This would work in an even nicer way with a central reverse proxy setup - the caching and proxying would then take place on a different machine so that the service host could even go down during maintenance. A more advanced solution would always keep a regularly updated cache but only serve its contents once the service goes down (for whatever reason).
Make a small tool or script that creates a static component registry dump that mimics the actual registry in that it contains the following pages at the expected locations:
/rest/registry/profiles
/rest/registry/profiles/{id}
/rest/registry/profiles/{id}/xml
/rest/registry/profiles/{id}/xsd
/rest/registry/components
/rest/registry/components/{id}
/rest/registry/components/{id}/xml
/rest/registry/components/{id}/xsd
For all non-deleted ids. For non-public ids, maybe best to only allow
/xsd
and/xml
.Also create a notification page at:
/
+/index.html
+/index.jsp
It can be used as a drop-in replacement by serving the static files during maintenance to the actual component registry or its host. This can be done either on the same server by reconfiguring the HTTP server, or on another host combined with an update of the DNS entry in case of maintenance that makes the host unavailable (e.g. maintenance at the hosting provider).
We could even perform this at regular intervals and host a fallback 'shadow component registry' that can be switched on when needed (even automatically).
The text was updated successfully, but these errors were encountered: