Ok, it would appear that original handshake timeout was 15 seconds, the timeout functionality was added at the same time as the test case.
I should probably change the timeout back to 15 seconds. This still doesn't explain why the test also passes on my systems or jdk 8 on jenkins? Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Peter <j...@zeus.net.au> Sent: 11/12/2015 11:04:39 am To: dev@river.apache.org <dev@river.apache.org> Subject: Re: Preparation for Release - one more volunteer needed Yes, check them in batch by batch please. Jenkins appears to have some build env settings problems on some executor nodes. This is unrelated to River, but is causing instability. There are two known test failures, one junit MuxStartTimeoutTest the other is a qa test for reggie, MultihomedClientTest, the latter test seems to be having some issues establishing the network config. So the only test river fails is MuxStartTimeoutTest. The current default system property setting for org.apache.river.jeri.handshakeTimeout is 360000. But the javadoc states 120000 (2 minutes). The test only waits 35000 milliseconds We should probably change the mux timeout back to the javadoc default and change the test to suit. The timeout was changed from 150000 when contention was occurring on startLock during testing. The contention has been fixed now, so we can set the timeout back to default, the contention was caused by increased concurrency. As for the test timing, it actually passes on my systems, but I was going to leave sorting the test failure for River 3.0.1 Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Patricia Shanahan <p...@acm.org> Sent: 11/12/2015 10:06:05 am To: dev@river.apache.org Subject: Re: Preparation for Release - one more volunteer needed I have some config files modified. Would you like me to check files in batch-by-batch, or wait until I have a lot of them done? I got a "Jenkins build is still unstable" when I checked in the update to the RAT script. When do you expect that to go away? On 12/9/2015 4:15 PM, Peter wrote: > Yes, check them in, I'll test them, the integration tests are running again >now, so we'll quickly identify any problems. > > Peter. > > Sent from my Samsung device. > Include original message > ---- Original message ---- > From: Patricia Shanahan <p...@acm.org> > Sent: 10/12/2015 12:00:10 am > To: dev@river.apache.org > Subject: Re: Preparation for Release - one more volunteer needed > > Note that this is not quite a release candidate. I'm working on fixing > some missing license statements in scripts and configuration files. > > I am also working on getting together a build environment, having not > built River for some time. > > Normally, I would wait for the script changes until I can build, so that > I can test what I am doing. In the current situation, would it be better > to do the changes, and check them in, without testing them? > > Patricia > > On 12/8/2015 4:25 PM, Peter wrote: >> Thanks Brian, >> >> Brad, >> >> The code is now in River's trunk branch. >> >> All com.sun.jini.* packages have changed to org.apache.river.* >> >> Some configuration options have changed since 2.2, ExecutorService has >>replaced TaskManager, where specified. >> >> Codebase grant's to URL's in policy files now by default, no longer >>resolve to ip addresses, this was done for two reasons: >> >> 1. To reduce dns calls. >> 2. To allow multiple codebase servers with different ip addresses to serve >>one domain name for increased redundancy or fail over. >> >> There's a system property that you can set if you need to revert to the >>previous behaviour. >> >> Interested to know how it goes. >> >> Regards, >> >> Peter. >> >> >> >> >> Sent from my Samsung device. >> Include original message >> ---- Original message ---- >> From: Bryan Thompson <br...@systap.com> >> Sent: 09/12/2015 05:38:52 am >> To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee >><be...@systap.com> >> Subject: Re: Preparation for Release - one more volunteer needed >> >> Peter, >> >> Brad (Cc) is working to put the River 3 candidate release into CI for our >> platform. This will allow us to test it in the highly available >> replication cluster mode of the database. >> >> Thanks, >> Bryan >> >> ---- >> Bryan Thompson >> Chief Scientist & Founder >> SYSTAP, LLC >> 4501 Tower Road >> Greensboro, NC 27410 >> br...@systap.com >> http://blazegraph.com >> http://blog.blazegraph.com >> >> Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance >> graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints >> APIs. Blazegraph is now available with GPU acceleration using our >>disruptive >> technology to accelerate data-parallel graph analytics and graph query. >> >> CONFIDENTIALITY NOTICE: This email and its contents and attachments are >> for the sole use of the intended recipient(s) and are confidential or >> proprietary to SYSTAP. Any unauthorized review, use, disclosure, >> dissemination or copying of this email or its contents or attachments is >> prohibited. If you have received this communication in error, please >>notify >> the sender by reply email and permanently delete all copies of the email >> and its contents and attachments. >> >> On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeusnet.au> wrote: >> >>> Thanks Patricia, >>> >>> We need at least three binding votes for release, at the very least we >>> need one more committer willing to assist with the release process >>> >>> Any volunteers? We cannot do it without you. >>> >>> Regards, >>> >>> Peter. >>> >>> Sent from my Samsung device. >>> Include original message >>> ---- Original message ---- >>> From: Patricia Shanahan <p...@acm.org> >>> Sent: 08/12/2015 01:54:08 pm >>> To: dev@river.apache.org >>> Subject: Preparation for Release >>> >>> This is probably unnecessary, but I wanted to make sure everyone >>> understands the requirements for casting binding votes in favor of a >>> release. See http://www.apache.org/legal/release-policy >>> >>> In particular "Before casting +1 binding votes, individuals are >>>REQUIRED >>> to download all signed source code packages onto their own hardware, >>> verify that they meet all requirements of ASF policy on releases as >>> described below, validate all cryptographic signatures, compile as >>> provided, and test the result on their own platform" >>> >>> I am preparing for this by working on being able to build and test >>>River >>> on one of my computers. >>> >>> Patricia >>> >>> >> >> > >
