.
Include original message
Original message
From: Gregg Wonderly <gr...@wonderly.org>
Sent: 07/12/2015 08:09:36 am
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
Well Peter, there are lots of things one can do about load management. The
obvious solutions are v
g on,
>> but because it is uncontended, it only consumes 0.2% cpu, about the same as
>> our security architecture overhead (non encrypted).
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>>Include origin
.
Include original message
Original message
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 04/12/2015 04:57:43 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
> On Dec 4, 2015, at 1:16 AM, Peter <j...@zeus.net.au> wrote:
>
> Since Objec
iginal message
From: Bryan Thompson <br...@systap.com>
Sent: 03/12/2015 11:48:12 am
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: Trunk merge and thread pools
Great!
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC
, your help is most appreciated.
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan <p...@acm.org>
Sent: 04/12/2015 06:20:59 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
Although we don't have a formal r
If you have a real world workload that shows contention, we could make
serious progress on performance improvement - after 3.0 ships.
I am not even disagreeing with changes that are only shown to make the
tests more effective - after 3.0 ships.
I am unsure about whether Peter is tilting at
With a handful of clients, you can ignore contention. My applications have 20s
of threads per client making very frequent calls through the service and this
means that 10ms delays evolve into seconds of delay fairly quickly.
I believe that if you can measure the contention with tooling, on
.
Thanks,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan <p...@acm.org>
Sent: 05/12/2015 12:01:04 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
Are there any practical things I can do to ex
variable and run the script. That would be very helpful.
Thanks,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan <p...@acm.org>
Sent: 05/12/2015 12:01:04 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread
Thank you.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan <p...@acm.org>
Sent: 05/12/2015 03:02:21 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
During the gap between releases, it seems Rat has changed fro
.
Include original message
Original message
From: Bryan Thompson <br...@systap.com>
Sent: 03/12/2015 11:48:12 am
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: Trunk merge and thread pools
Great!
Bryan Thompson
Chief Scientist & Founder
SYSTAP
Care to share more of your insight?
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Gregg Wonderly <ge...@cox.net>
Sent: 03/12/2015 06:37:15 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
The original use of thread p
com>
Sent: 02/12/2015 11:25:03 pm
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: Trunk merge and thread pools
Ah. I did not realize that we were discussing a river specific ThreadPool
vs a Java Concurrency classes ThreadPoolExecutor. I assume that it would
be
original message
Original message
From: Bryan Thompson <br...@systap.com>
Sent: 02/12/2015 09:46:13 am
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: Trunk merge and thread pools
Peter,
It might be worth taking this observation about the thread pool beh
; replacement.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
> Include original message
> Original message
> From: Bryan Thompson <br...@systap.com>
> Sent: 02/12/2015 09:46:13 am
> To: <dev@river.apache.org> <dev@river.apache.
mes 0.2% cpu, about the same as
> our security architecture overhead (non encrypted).
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
> Include original message
> Original message
> From: Bryan Thompson <br...@systap.com>
> Sent: 02/12/2015 11:25
from my Samsung device.
Include original message
Original message
From: Patricia Shanahan <p...@acm.org>
Sent: 02/12/2015 01:02:56 am
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools
Thanks for getting that done.
There is a more general message in your threa
good idea, will do.
Sent from my Samsung device.
Include original message
Original message
From: Bryan Thompson <br...@systap.com>
Sent: 02/12/2015 09:46:13 am
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: Trunk merge and thread pools
Peter,
Peter,
It might be worth taking this observation about the thread pool behavior to
the java concurrency list. See what feedback you get. I would certainly
be interested in what people there have to say about this.
Bryan
Thanks for getting that done.
There is a more general message in your thread pool observation. Any
time we do something a certain way for performance, we should be
prepared for the possibility that the opposite choice will become better
in the future.
In general, there has been a trend for
20 matches
Mail list logo
