Distributed multi server and core wiring

[mlidbom]

Hi.

We are using a number of fundamentally different Solr cores in different services/components that in principle has nothing what so ever to do with each other.

In the end though, two or more will be be used from composite user interfaces that pulls in components from many services/components into one interface for the user.

We want each of these components to be able to do their own wiring with no need to take into account any other Solr components that may be running in the same process in the end.

As far as we could tell the existing Windsor SolrNetFacility cannot provide this ability.
This branch is our progress so far in trying to modify the facility to easily support enabling this scenario.

It is very much a work in progress but I figure that the sooner we get feedback on the approach we've chosen so far the better.

Regards /Magnus Lidbom

[stephenpope]

This seems a good idea. Is this all you need to solve the issue or is there more you need to submit ?

[mlidbom]

This is mostly working for us but there are some things that I feel need to be improved before merging.
(Please bear with me as I realized half way through this comment that I'm half explaining, half figuring it out as I ramble on :) )

Most importantly: If no unnamed ISolrConnection is registered, then resolving an ISolrConnection or a component that depends on an ISolrConnection will result in an ISolrConnection that is essentially a random choice among the named ISolrConnections that are registered in the container. This is very likely to result in strange and hard to track down bugs when requests that the developer expected to be dispatched to one core is instead dispatched to another. The same goes for other components that depend on the unnamed ISolrConnection

The simplest idea I've had so far is to throw an InvalidOperationExeption exception, via a FactoryMethod registration, on any attempt to resolve an unnamed ISolrConnection in this scenario. The exception message would describe this problem.

That would prevent such problems, by forcing the developer to be explicit about dependencies. But it seems like a bit of a kludge, and the details of how to "be explicit about dependencies" is hidden within the facility. For instance the names of the registered components.

I suspect that an elegant solution would require larger amounts of refactoring, and might require changes that would not be backwards compatible. Possible backwards compatible changes to the type system would be to add generic versions of non-generic interfaces.

Unfortunately I think might also be a kludge. I think that the real problem is most likely that an abstraction is missing. The Solr server. A clear simple interface might be something like this:

  container.GetOrAddSolrFacility()
     .GetOrAddServer(SolrServerName, SolrServerUrl) //Both name and url so that logical and physical deployment can remain separate. In one deployment two components may share a solr server, in another they may use different ones. 
    .AddCore<TModel>(CoreName) //No need for URL since the server knows about the URL

Possibly server should be registered only by URL so that we could try to ensure that one actual Solr server is represented by one instance in the container. That would be virtually impossible to be entirely sure of though, considering load balancers, multiple IPs pointing at the same machine etc.

Also I'm not sure how that could be made to work with the existing types, or if it would require changes outside of the wiring for IOC. Possibly adding a server would essentially equal the existing registration done in the Init method, except that now all the component names would be based on the server name?

As you can tell I think this can be greatly improved, but I'm not quite sure how yet, or if I will be able to find the time to do it right....

[mlidbom]

Small, probably less than useful, comment about this.
As of yet we have not used this code widely. Further improvements are on hold and less than likely to actually occur since I am very busy with other work and the changes presented in this pull request so far do actually work.

If you consider them to be an improvement I would merge them as is for now, because I don't realistically believe that I will have a better, more SOLID, bit of code for you any time soon.
I personally do believe that it is a significant improvement, I was just hoping to have something much better done before I suggested really merging it.

Well life tends not to give us exactly what we want :(

Best Regards /Magnus

[mausch]

Cheers, I'm awfully busy at the moment but I'll try to review it when I get some time.