river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: ServiceDiscoveryManager
Date Thu, 03 Nov 2016 12:16:52 GMT
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.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Dawid Loubser <dawid@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. 

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. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message