To be honest, I've got no interest in Internet-visible services or discovery. Not that I want to discourage other people working on them. If that's your itch, then scratch away! :-)
Greg's new wiki page said one of the things that particularly hits home with me; "If it were easier to get up and running..." Absolutely, that's one of the things that I want to get sorted. I've spoken about it before and usually been told that it's the job of downstream projects to make 'stuff' easier. I kind of resent that attitude. There is no denying that there is a lot of truely brilliant stuff in downstream projects, that's no reason to leave using vanilla River as such a headache though. Other things that come to mind are the Gradle build and the distributed transaction manager. We should probably start thinking about a new roadmap as well. Yes, this is another "vision" thing, but now we're a TLP I think we're expected to have one. ;-) Cheers, Tom On Mon, Aug 1, 2011 at 1:10 AM, Peter Firmstone <[email protected]> wrote: > Patricia Shanahan wrote: >> >> On 7/31/2011 1:43 AM, Peter Firmstone wrote: >> ... >>> >>> * TaskManager - improve concurrency and remove the dependency on >>> Task.runAfter() in River code. >> >> ... >> >> I'm playing with implementing a subclass of ThreadPoolExecutor that >> modifies the number of threads based on the mean number of tasks over some >> recent time period. That way, the number of threads will not be a long term >> bottleneck, but threads will not be created and destroyed for short-lived >> bursts. >> >> I have an on-going concern, for all performance and concurrency work in >> River, that we have neither benchmarks nor access to real installations to >> instrument and observe. > > I'm having the same issue, I've noticed some Sun T2000's becoming available > on ebay for around $1000, 32GB ram, 8 cores which appear as 32 cpu's in the > system. > > The only problem might be Oracle's licensing, but this is the cheapest most > relevant hardware I can find at present. > > Object based benchmarks should be easy enough to create using MultitreadedTC > (included in test/lib), but this doesn't apply to integration testing and I > suspect the current qa suite might have some concurrency issues too. > > Peter. > >
