If you use DNS for fault-tolerance, if one repo goes down, it may take upwards of 15 minutes for the client side DNS cache to clear and use the new IP: this may be acceptable, depending on your requirements. A more reliable approach would be to use a load balancer to ping the distributed caches and either do an HTTP redirect or to have the load-balancer manage the connections, provided you have enough bandwidth. With the load balancer solution, if your primary load balancers go down, you could then use DNS to direct the client to a new geographic site, with a redundant set of load balancers. This fail-over of the load balancer would have upwards of a 15 minute delay (for some users); but then again your load balancers should not be going down at all.
Regards, Shane On 10/24/06, Brian Topping <[EMAIL PROTECTED]> wrote:
With the snapshots repo down, there was some discussion on IRC. Joakim mentioned there was some discussion of a resolution that was "DNS-like, not actual DNS" and it got me thinking DNS might be a better solution (possibly with RFC-2782 extensions) to resolve repositories. Apologies if this echos discussion at ApacheCon. This solves some problems: 1) Downtime at well-known repositories such as we are seeing today could be backed by the actual repository that released the code. If a central repository goes down, the source repository that provided the original artifact would act as a fallback. DNS is distributed, so there is no central point of failure for artifact resolution. 2) Authenticity of artifacts is validated by control of DNS. The current method of getting an artifact into the central repository isn't scalable. If you know someone well enough, they put your code into the repository. If you don't know someone, your request gets put on a list of things to do. It's the way it has to work with a central repo. But if the repo could be found by DNS resolution, anyone could publish. It's up to the client to decide if a jar with <groupId>org.viruswriters</groupId> is safe to depend on, and it can be resolved without burdening central repository maintainers to decide whether to publish it since the crew at viruswriters.org could simply add their external repository to DNS. Done. 3) Use of artifacts could be logged. I would like to be able to use log analyzers to know who is using my artifacts and what part of the world they are coming from. I can't do this with a central repository. If I have a sufficiently fast line, I should be able to run my own repo and collect these logs. Central repositories are still important, but their role would change to a fast cache of the distributed repos. Artifact suppliers would be mirrored if their artifacts were considered important enough and mirroring them would speed up builds for the masses, not because someone successfully campaigned to get their artifact in. WDYT? -b
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
