river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: Lookup Service Discovery using DNS?
Date Tue, 12 Jan 2010 16:46:06 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
> Either of these can be accomplished within the current River
> 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.


View raw message