>> From: [email protected] [mailto:[email protected]] >> Sent: Tuesday, January 12, 2010 7:20 AM >> To: [email protected] >> Subject: Re: Lookup Service Discovery using DNS? >> >> Just out of curiosity, why wouldn't it be taken on as a project within >> this group to do: >> a) Create an enhanced specification for Reggie to allow it to act as a >> global registry with sufficient permissions and scope. >> b) Create a new service which sole purpose is to act as a global > registry. >> >> Either of these can be accomplished within the current River > framework. >> >> Regards, >> Martin > > > Wrap UDDI in a ServiceRegistrar interface? > > > I'm curious what scaling numbers people have experienced for Reggie in > the real world. > > I've seen v2.1 Reggie scaled up to 4000 registered services and 2000 > event listeners on a LAN, and I've seen Reggie working across WAN > systems about half that size. In the steady state in healthy systems, > this works great. A couple of problems I've seen: > > > 1) when Reggie starts (or restarts), it gets hammered with new requests > as services and clients find it via lookup locator polling, and chaos > ensues. I've seen Reggie go non-linear and hang when it exceeds N > threads all waiting for RegistrarImpl.concurrentObj, where N is > something like 1000. In that regime, stack memory per thread matters a > lot too. > > 2) the implementation of RegistrarProxy.lookup(ServiceTemplate,int) > insists on unmarshalling all matches serially, which hangs for a long > time if any services have bad codebase jars (denial of service). This > weakest-link problem is exacerbated by WAN latencies. I have an > experimental patch that unmarshals in parallel, but it requires > cooperation of both Reggie and clients (i.e. changes to both > RegistrarProxy and ServiceDiscoveryManager). > > > The latter problem is solvable, but the former is hard. Reggie is > really sensitive to performance bottlenecks at startup. Rewriting > ReadersWriter to avoid using notifyAll() might help, perhaps borrowing > CAS tricks from ReentrantReadWriteLock. > > Chris >
Could it be possible to take an example out of Bittorrent/Gnutella where they require their services have a requirement to "hang around" for awhile to share --or-- have people volunteer to host "long-lived" Registries on their hardware. I have to believe from the current design/specifications that the current services were predominantly designed for LAN use (because of the use of multicast and is subsequent denial due to firewalls). Maybe making a new requirement/design of a global registry to only support Unicast and have it's sole purpose to share references to services that have been explicitly configured to support this idiom... Just my $.02 Martin
