Should we support automatic re-loading for resources and configuration loaded from the registry?

["Asankha C. Perera" <as...@wso2.com>]

Hi All

When we initially built the Registry/Repository support for Synapse (and 
the WSO2 ESB), we allowed the runtime to dynamically re-load changed 
resources at runtime. We even made some of these changes visible 
atomically to a message (i.e. if during the inSequence a message saw the 
revision 344 of a resource, and the resource changed to 345 on the 
remote registry when the response processing began, we let the same 
version seen by this message earlier [344] be seen during the 
outSequence as well)

However, this has added quite a bit of complexity to the code, and 
probability for bugs and uncertainty. For example, if someone changed an 
XSLT and XSD at the same time on the registry, its possible for a 
message to see one version of the XSLT and another version of the XSD etc..

Allowing configuration elements (such as Sequences and Endpoints) to be 
stored in the Registry has added some confusion as well. Typically a 
production configuration is static, and any updates (esp in Production) 
is controlled by manual human interaction. Thus I do not see much value 
in allowing the configuration elements to be updated without the 
explicit knowledge and control of the ESB admins.. this also creates 
problems for us developers, who want to improve the JMX support and 
other features of Synapse, as we cannot let a definition just vanish to 
thin air and another configuration element to become available 
automatically.. I am ready to accept the proposed changes to support 
"includes" within a synapse.xml, and also the suggested JAR type 
archives as a mechanism to update/manage the configuration.

So my proposal about Registry caching, is to always cache forever any 
resources referred to from the Registry. We will then expose a new JMX 
function which will allow us to clear the full cache. This gives:

1) Full human control for resources loaded from the registry
2) Allows someone to update content on the Registry, and still make 
Synapse see the updated copies after a manual cache reset - when required
3) Allows some level of disconnected operation (e.g. once resources are 
loaded - e.g. WSDLs), i.e. the services on Synapse can continue even if 
the Registry becomes inaccessible

Your thoughts are welcome

asankha

-- 
Asankha C. Perera

WSO2 - http://wso2.org
http://esbmagic.blogspot.com