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
Delayed unmarshalling is a big deal for my use!
Gregg
Sent from my iPhone
> On Nov 1, 2016, at 6:27 AM, Peter Firmstone
> wrote:
>
> I've finally got ServiceDiscoveryManager to a stage where I feel like it's
> been completely brought up to date.
>
> Origin
r 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 condition
6:43 am
To: dev@river.apache.org
Subject: Re: ServiceDiscoveryManager
Delayed unmarshalling is a big deal for my use!
Gregg
Sent from my iPhone
> On Nov 1, 2016, at 6:27 AM, Peter Firmstone
>wrote:
>
> I've finally got ServiceDiscoveryManager to a stage where I feel lik
rs,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Dawid Loubser
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 existi
I have a question as to the behaviour of ServiceDiscoveryManager.
When i create a lookupCache with a ServiceDiscoveryListener in the
constructor, very seldom i miss a ServiceAdded event for a service that
is discovered,
while another lookupCache created with the same ServiceDiscoveryManager
With TaskManager.Task.runAfter, throughput wasn't significant enough for
this race to occur.
If I make the ExecutorService single threaded, the error doesn't occur
as the tasks are executed in correct dependency order, however, when the
ExecutorService has a lot of threads ready, the tasks are
This test smells broken?
I modified the output to read in milliseconds.
Relevant ServiceDiscoveryManager method under test:
public ServiceItem[] lookup(ServiceTemplate tmpl,
int minMatches,
int maxMatches
I don't think it is just a matter of latency. When I last looked closely
at TaskManager, it appeared to me that it kept each task in the runAfter
checking list until the task returned from its run method. That way, a
dependent task was prevented from running until completion of the task
on whic
- Original message -
> I don't think it is just a matter of latency. When I last looked closely
> at TaskManager, it appeared to me that it kept each task in the runAfter
> checking list until the task returned from its run method. That way, a
> dependent task was prevented from running
So, after spending some time thinking and going over notes...
SDM EventReg keeps tally of the latest event ID, and SDM attempts to execute
tasks in order for each ServiceID, so this seems the best place to store two
small PriorityQueue's, one for pending tasks, the other for executing tasks.
Ca
One of the primary benefits of callbacks is that the application can then be
the primary control point for thread assignment to those tasks.
That removes the whole issue of threading and scaling as a support and some
test requirements.
Gregg
Sent from my iPhone
> On Jan 17, 2014, at 5:46 PM,
On 7/05/2013 8:17 PM, Peter Firmstone wrote:
This test smells broken?
I modified the output to read in milliseconds.
Relevant ServiceDiscoveryManager method under test:
public ServiceItem[] lookup(ServiceTemplate tmpl,
int minMatches
riance.
Cheers,
Greg.
On Tue, 2013-05-07 at 06:17, Peter Firmstone wrote:
> This test smells broken?
>
> I modified the output to read in milliseconds.
>
> Relevant ServiceDiscoveryManager method under test:
>
> public ServiceItem[] lookup(ServiceTemplate tmpl,
&g
Cheers,
>
> Greg.
>
> On Tue, 2013-05-07 at 06:17, Peter Firmstone wrote:
> > This test smells broken?
> >
> > I modified the output to read in milliseconds.
> >
> > Relevant ServiceDiscoveryManager method under test:
> >
> > public ServiceIt
curate. Matter of
fact, waiting for a task switch could cause at least that much variance.
Cheers,
Greg.
On Tue, 2013-05-07 at 06:17, Peter Firmstone wrote:
This test smells broken?
I modified the output to read in milliseconds.
Relevant ServiceDiscoveryManager method under test:
I recently updated RetryTask to implement RunnableFuture (it had very similar
methods), it also no longer implements Task.runAfter which has been pushed down
to subclasses that use it (aka those in ServiceDiscoveryManager) it wouldn't
take much effort to add functionality to RetryTask to
Replacement of TaskManager with ExecutorService.
ServiceDiscoveryManager:
1.Complex dependency relationships.
2.Dependency is the exception, not the norm, existing runAfter(List
task, int position) implementations, changed to dependsOn(CacheTask t),
iteration being performed by the caller
I've noticed via experimentation with the test suite that
ServiceDiscoveryManager doesn't detect attribute changes to a service if
it uses Entry's with final fields. I'm not sure of the root cause, but
it could have something to do with Reggie's implementation of th
results in less
time to service lookups.
ServiceDiscoveryManager not exiting lookup loop when serviceItems.length>=
minMatches
--
Key: RIVER-466
URL: https://issues.apache.
20 matches
Mail list logo
