The federation connector is not well behaved when it comes to a number of very common situations. In particular, there seem to be a lot of failures when attempting to repeatedly find nodes by UUID. I suspect that the cache layer is not being updated correctly.

There are also several issues with the fundamental design. Currently, all operations against the cache and any sources are performed serially, despite the fact that each connector's processing of requests submitted to it is complete independent of all other connectors. This means that all source connector processing could be parallelized.

Another issue is that when a CompositeRequest is submitted to the federation connector, these requests are treated as if they are being done within a single (logical) transaction. However, often times the processing of a request submitted to the federated connector results in one or more requests being made to the source connectors, and these source requests are submitted individually (rather than in a single CompositeRequest corresponding to that submitted to the federated connector). Thus, there is no tie between the source connections and federated connection. Although we don't supported distributed transactions, this certainly doesn't come close to helping align the logical transactions of each connector.

Third, the federation connector does not optimize for some common situations, such as a single mirror projection (e.g., "/ => /", where the federation connector is really just mirroring another source), an offset projection (e.g., "/ => /a/b" or "/c/d => /", where the federation connector is mirroring a subset of another connector or prepends a leading path), a mirror-with-branch case (e.g., "/ => /" for source A, and "/jcr:system => /jcr:system" for source B). The latter condition is likely to be used in the JCR implementation to project a single "/jcr:system" branch (which will exist in its own workspace in a JCR repository) into each normal JCR workspace.

Finally, as just mentioned, the federation connector has the potential to be used in a number of situations within other non-extension projects (e.g., "dna-jcr"). This is not really feasible with the current connector, since it is a normal extension and not a first-class feature of the 'dna-graph'. Therefore, the federation connector should be moved into 'dna-graph' similar to the In-Memory connector.