Self check routine for connectors

[vasilievip]

Does it make sense to add self-check callbacks into connector SPI?

Here is the scenario:

1. Connector rely on some configuration in underlying repository and at start-up this configuration was OK
2. Connector did import and register in modeshape types from underlying repo
3. At some point configuration in underlying repo was changed and connector can't function w/o restart of modeshape

Does it make sense to have something in modeshape to ping connector and validate its state continuously? Or this completely up to developers of connector?

[hchiorean]

Runtime type changes are of 3 flavors: additions, removals and edits. Additions should not impact the connector in any way. Edits are strongly discouraged because they can render the repository inconsistent (regardless of whether it has connectors or not). Removals are the only case when we can potentially do something (i.e. tell the connector that a node-type has been removed)

That being said, I don't see a valid reason why a client application would, at runtime, change the node-types registered by a connector: the API allows this of course, but logically it makes no sense to me because a connector/external system is a self-contained unit. Clients should have no reason to mess with its node types. They should instead define their own types as CNDs and use those for "dynamic" type changes.

[vasilievip]

When connector, for example, can't connect to underlying repo does it make sense to detect that periodically and do something at the engine level?

[hchiorean]

Not sure I understand: the repository uses the connectors to retrieve & store external information, not the other way around. The external system is completely independent of the repository in terms of its lifecycle. If an external system goes down for whatever reason, the connector will throw an exception and ModeShape will use that.

[vasilievip]

Connector can throw an exception which is really hard to understand and not obvious to figure out the root cause in some cases (connection refused is most simplest case, imagine content types mismatch). Idea here is to force developer to implement some api which will be triggered periodically by engine and if connector is in invalid state - do not store content into and use results from API call to present previously collected issues.

This can be done at connector level, but does it make sense to have such function on engine level? 

[rhauch]

I can see this going both ways.

On one hand, I do understand where, in some cases, having the engine periodically poll the connector to see if all things are "healthy" would make things easier for connectors that could benefit from this behavior.

On the other hand, not all connectors need this behavior, so forcing them to have it in a base class seems to raise the bar for anyone creating a connector. We want to lower the bar, if anything. Not only do we need to think about making it work mechanically, but we also would need to provide a way for the poll interval (and anything else?) to be configurable.

[vasilievip]

With self check routine at engine level issues found can be presented on engine status page in unified way via engine API. W/o support from engine -connectors must report issues somewhere else...