river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From m..@martinwills.com
Subject RE: Lookup Service Discovery using DNS?
Date Tue, 12 Jan 2010 16:57:21 GMT
>> From: mdw@martinwills.com [mailto:mdw@martinwills.com]
>> Sent: Tuesday, January 12, 2010 7:20 AM
>> To: river-dev@incubator.apache.org
>> 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


View raw message