Build failed in Jenkins: river-qa-refactor-arm-jdk8 #2

See -- [...truncated 306 lines...] [echoproperties] user.country=US [echoproperties] user.dir= [echoproperties] user.home=/home/jenki

Build failed in Jenkins: river-qa-refactor-arm-jdk8 #1

See -- [...truncated 7153 lines...] [echoproperties] user.country=US [echoproperties] user.dir= [echoproperties] user.home=/home/jenk

Re: Little known facts about Remote objects

We might be able to get some benefit more portably by writing a Java program that spawns a specified number of threads, all of which continuously increment the same AtomicLong. That will cause both CPU load and, with multiple processor chips, bus activity. Run it, along with River tests, specif

Re: Little known facts about Remote objects

Thanks Patricia, Good to have someone with experience who can explain why. Your parstore program is interesting. Perhaps I should obtain a second hand 8 core 32 way T2000, I'll investigate this option in the new year. In spite of fixing synchronization errors, I'm not seeing contention during

Re: Little known facts about Remote objects

I don't think you need to assume increased JVM optimization to explain the phenomenon. It is typical of what happens when increasing thread safety in a system that has been subject to testing, but not full thread safety design and code review. Testing, and fixing test failures, tends to eliminate

Re: Little known facts about Remote objects

What I've found during the refactoring process is that fixing one data race bug will expose another. The latest test failure on multiple architectures has previously never failed during testing (its the only test failure on ubuntu x64 and arm jdk7), here a boolean field is written to while sync

Re: Fw: Re: Jenkins - jtreg test suite

Thanks Jake, I'll set up a test build for it on the weekend. Regards, Peter. - Original message - > Please verify using buildslave "ubuntu1", minerva, with path > $HOME/tools/jtreg/latest/linux/bin/jtreg and jtreg lib path available at > $HOME/tools/jtreg/latest/lib/ > > -Jake > > > O

Re: River 3.0 beta release candidate

The way that services are instantiated and setup is an implementation detail. When I think of compatibility I think of the API and the lookup methods. We think of compatibility from a client point of view. From the client point of view, using a service looks like this: - Use multica

Re: River 3.0 beta release candidate

I'm happy to accept whatever release version number that the committers decide when that time comes. I think it best to narrow our focus for now on how to proceed with the release process. Regards, Peter. - Original message - > > The way that services are instantiated and setup is a

Re: River 3.0 beta release candidate

I think changing services to use safe construction techniques is enough to cause the version jump. At this point I've allowed services to continue unsafe construction practices, while logging a SEVERE warning when the Commission interface isn't implemented, rather than fail. This is a fundamen

Re: River 3.0 beta release candidate

- Original message - > > Assuming that there aren’t major incompatibilities, I think that would > be a “minor” version change according to our versioning policy, so we’d > be looking at the “2.3” branch rather than a “3.0” release. > > I’m still unnerved by the massive amounts of changes

Re: Little known facts about Remote objects

On 12/17/2013 7:42 AM, Gregg Wonderly wrote: ... As I’ve discussed here before, one of the most destructive activities that has happened in the JDK, has been the “enforcement” of “volatile” vs “non-volatile” correctness in the activities of the JIT. The standing example, is this: class foo imp

Re: Fw: Re: Jenkins - jtreg test suite

Please verify using buildslave "ubuntu1", minerva, with path $HOME/tools/jtreg/latest/linux/bin/jtreg and jtreg lib path available at $HOME/tools/jtreg/latest/lib/ -Jake On Sun, Dec 15, 2013 at 2:52 PM, Peter Firmstone < peter.firmst...@zeus.net.au> wrote: > Any chance of getting jtreg installe

Re: Little known facts about Remote objects

I want to reiterate what Peter is saying with perhaps some different words and experiences. When Java 5 came out, for the first time, JDK/JRE development started focusing on removing “locks”. That is improving scaling, by changing libraries and the runtime environment to not assert “fences” or

Re: River 3.0 beta release candidate

Assuming that there aren’t major incompatibilities, I think that would be a “minor” version change according to our versioning policy, so we’d be looking at the “2.3” branch rather than a “3.0” release. I’m still unnerved by the massive amounts of changes to both code and tests in the qa_refac

Re: Little known facts about Remote objects

Not sure if I’d call that “little-known”. Greg. On Dec 17, 2013, at 9:12 AM, Peter wrote: > Remote objects, when exported are exposed to multiple threads. > > Even when a Remote object only has one client, the clients calls will be > despatched via a thread pool to the exported object, every

Little known facts about Remote objects

Remote objects, when exported are exposed to multiple threads. Even when a Remote object only has one client, the clients calls will be despatched via a thread pool to the exported object, every method call is likely to be invoked by a different thread. If your exported objects aren't thread sa

River 3.0 beta release candidate

When the qa_refactor branch stabilises, I plan to merge trunk and provide a beta release for client compatibility testing. Changes made have been focused on making our code thread safe, there are significant changes internally, the public api remains focused on backward compatibility, however i