Delayed unmarshalling is a big deal for my use! Gregg
Sent from my iPhone > On Nov 1, 2016, at 6:27 AM, Peter Firmstone <peter.firmst...@zeus.net.au> > wrote: > > I've finally got ServiceDiscoveryManager to a stage where I feel like it's > been completely brought up to date. > > Originally SDM's LookupCache had some latent race conditions that became > evident after I created a non blocking DynamicPolicyProvider. > > I spent some time refactoring it, I separated LookupCacheImpl from SDM, into > it's own file, but was never happy with remote method calls and filtering > being performed whist synchronized on a monitor. > > I've finally got it sorted nicely now, so it's much easier to understand. > I've used some Java 8 features like ConcurrentMap.computeIfPresent, but I'm > finally happy with it. > > Logging in SDM is now processed by a single threaded executor, so logging > doesn’t interfere with concurrency, yep it's a complex class and logging > helps you figure out what's going on. > > The best feature though, is utilising the new ServiceRegistrar default lookup > method. > > SDM's and LookupCache's api is unchanged, you just configure it how you want > it to behave. > > So if you want the existing slow insecure behaviour where you download > everything, authenticate and filter later you can keep doing that. > > However, if you want security and performance, with delayed unmarshalling, > don't want to download services you can't authenticate or your filter doesn’t > match locally using logical comparisons of attributes, you can do that too. > Because you only download what you want when you need it, performance is gr8. > > I've written a bunch of new tests too. I haven't committed the latest > changes. > > Oh and security doesn't require you to implement ProxyTrust (complex and > confusing), because the service is authenticated prior to download, not after. > > Cheers, > > Peter. > > Sent from my Samsung device. >
