Thanks Dawid, There's hope for this project yet B)
Can't wait for people to try it out to see just how fast the new code is ;) We've eliminated unnecessary dns calls, the policy provider and RFC3986 URLClassLoader (used for smart proxy's) are likely to remain unchallenged in performance. The Uri class they depend on uses bit shift operations for string case normalisation. My hotspots now are native socket calls, so while we're probably not the fastest when comparing serialization frameworks, when you throw in dynamic code downloads and security, I'd like to think we can shake up the competition just a little ;) It'd be nice if someone could test it at scale, so we can optimise for that. Our optimisations aren't ugly either, the code if anything, is more readable, well commented and easier to understand than it used to be. Cheers, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Dawid Loubser <da...@travellinck.com> Sent: 03/11/2016 04:44:28 pm To: dev@river.apache.org Subject: Re: ServiceDiscoveryManager Wow. I think this is quite a big deal, going forward... I've never liked the existing behaviour, and it seems like you have very thoroughly worked around those issues. I really look forward to finding some time to play with your newer version - but I just wanted to personally thank you for the amazing work. regards, Dawid Loubser On 01/11/2016 13:27, Peter Firmstone 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. > >
