[VOTE] Releasing Wagon 2.11

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[VOTE] Releasing Wagon 2.11

Dan Tran
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
Am 2016-12-24 um 04:07 schrieb Dan Tran:
+1

SHA1 is fine, site is fine. Builds passes on Windows but constantly
fails on non-Windows, here on my FreeBSD machine as well as on our
Jenkins Ubuntu slave. It should probably investigated for the 3.0 release.

Michael




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Dan Tran
Thank Michael

  * Test failures at windows are intermittent.  It is a known issue since
the last few versions
  * No issue at my local redhat 7/java7 build
  * I am seeing test failures at
https://builds.apache.org/view/All/job/maven-wagon/1323/    starting with
your change for WAGON-472. Dont think it is related, could be from build env


Thanks

On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov <[hidden email]> wrote:

> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>
>> Hi,
>>
>> We have fixed 18 issues:
>> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>> ectId=12318122&version=12333396
>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>> ectId=12318122&version=12333396>*
>>
>> There are still issues left in JIRA:
>> *<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20created%20DESC%2C%20priority%20DESC
>> <<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20created%20DESC%2C%20priority%20DESC>*
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/maven-1313
>> https://repository.apache.org/content/repositories/maven-
>> 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip
>>
>> Source release checksum(s):
>> wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
>> 00c58abfa5
>>
>> Staging site:
>> *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
>> <http://maven.apache.org/components/wagon-archives/wagon-LATEST/>*
>>
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>> <https://maven.apache.org/guides/development/guide-testing-releases.html>
>> Vote open for 72H + 48H to accomodate for holidays
>>
>
> +1
>
> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
> on non-Windows, here on my FreeBSD machine as well as on our Jenkins Ubuntu
> slave. It should probably investigated for the 3.0 release.
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
Am 2016-12-25 um 18:45 schrieb Dan Tran:
> Thank Michael
>
>   * Test failures at windows are intermittent.  It is a known issue since
> the last few versions
>   * No issue at my local redhat 7/java7 build
>   * I am seeing test failures at
> https://builds.apache.org/view/All/job/maven-wagon/1323/    starting with
> your change for WAGON-472. Dont think it is related, could be from build env

This is build env. I have tested Wagon on Windows and FreeBSD before any
patching. Windows was fine, FreeBSD failed for those two cases. It also
passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I
have good news: I have been working on the unit tests in genereal the
last two days by migrating to Jetty 8 (last Java 1.6 supported) version
and found several bugs in Wagon HTTP Provider and the unit test setup
itself. I will report them shortly.

Michael

> On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov <[hidden email]> wrote:
>
>> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>>
>>> Hi,
>>>
>>> We have fixed 18 issues:
>>> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>> ectId=12318122&version=12333396
>>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>> ectId=12318122&version=12333396>*
>>>
>>> There are still issues left in JIRA:
>>> *<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>> 20created%20DESC%2C%20priority%20DESC
>>> <<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>> 20created%20DESC%2C%20priority%20DESC>*
>>>
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/maven-1313
>>> https://repository.apache.org/content/repositories/maven-
>>> 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip
>>>
>>> Source release checksum(s):
>>> wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
>>> 00c58abfa5
>>>
>>> Staging site:
>>> *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
>>> <http://maven.apache.org/components/wagon-archives/wagon-LATEST/>*
>>>
>>> Guide to testing staged releases:
>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>> <https://maven.apache.org/guides/development/guide-testing-releases.html>
>>> Vote open for 72H + 48H to accomodate for holidays
>>>
>>
>> +1
>>
>> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
>> on non-Windows, here on my FreeBSD machine as well as on our Jenkins Ubuntu
>> slave. It should probably investigated for the 3.0 release.
>>
>> Michael
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Dan Tran
Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
same test failure??

Do you think we should cancel the vote and wait for your fix?

Thanks

-Dan

On Sun, Dec 25, 2016 at 10:34 AM, Michael Osipov <[hidden email]>
wrote:

> Am 2016-12-25 um 18:45 schrieb Dan Tran:
>
>> Thank Michael
>>
>>   * Test failures at windows are intermittent.  It is a known issue since
>> the last few versions
>>   * No issue at my local redhat 7/java7 build
>>   * I am seeing test failures at
>> https://builds.apache.org/view/All/job/maven-wagon/1323/    starting with
>> your change for WAGON-472. Dont think it is related, could be from build
>> env
>>
>
> This is build env. I have tested Wagon on Windows and FreeBSD before any
> patching. Windows was fine, FreeBSD failed for those two cases. It also
> passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I
> have good news: I have been working on the unit tests in genereal the last
> two days by migrating to Jetty 8 (last Java 1.6 supported) version and
> found several bugs in Wagon HTTP Provider and the unit test setup itself. I
> will report them shortly.
>
> Michael
>
>
> On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov <[hidden email]>
>> wrote:
>>
>> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>>>
>>> Hi,
>>>>
>>>> We have fixed 18 issues:
>>>> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>>> ectId=12318122&version=12333396
>>>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>>> ectId=12318122&version=12333396>*
>>>>
>>>> There are still issues left in JIRA:
>>>> *<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>>> 20created%20DESC%2C%20priority%20DESC
>>>> <<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>>> 20created%20DESC%2C%20priority%20DESC>*
>>>>
>>>> Staging repository:
>>>> https://repository.apache.org/content/repositories/maven-1313
>>>> https://repository.apache.org/content/repositories/maven-
>>>> 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip
>>>>
>>>> Source release checksum(s):
>>>> wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
>>>> 00c58abfa5
>>>>
>>>> Staging site:
>>>> *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
>>>> <http://maven.apache.org/components/wagon-archives/wagon-LATEST/>*
>>>>
>>>> Guide to testing staged releases:
>>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>>> <https://maven.apache.org/guides/development/guide-testing-
>>>> releases.html>
>>>> Vote open for 72H + 48H to accomodate for holidays
>>>>
>>>>
>>> +1
>>>
>>> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
>>> on non-Windows, here on my FreeBSD machine as well as on our Jenkins
>>> Ubuntu
>>> slave. It should probably investigated for the 3.0 release.
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
Am 2016-12-25 um 19:51 schrieb Dan Tran:
> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
> same test failure??

Yes, I had always the same two build failures as the Ubuntu box in
contrast to Windows.
I am currently testing the same code on different JDKs also to see
wether this is a JDK issue or test test setup issue.

Windows 10 Pro, 64 bit:
* Oracle JDK 7 Update 80: pass
* Oracle JDK 8 Update 112: pass (1)
* OpenJDK 7 (Azul Zulu) Update 121: pass

FreeBSD 10.3-RELEASE-p11, 64 bit:
* OpenJDK 7 Update 111: pass
* OpenJDK 8 Update 112: pass

All ran with Maven 3.3.9.

(1) Some HTTP Provider (preemptive) tests are flaky, I do not know why
yet, strangely they always pass when run from inside Eclipse.

> Do you think we should cancel the vote and wait for your fix?

We could, yes. This would also include other bugfixes in the code,
especially with HTTP PUT.

I'll try to push a feature branch on this today and will have you a look
at it. If this is fine, we can merge into master and reroll the vote.

Michael

> On Sun, Dec 25, 2016 at 10:34 AM, Michael Osipov <[hidden email]>
> wrote:
>
>> Am 2016-12-25 um 18:45 schrieb Dan Tran:
>>
>>> Thank Michael
>>>
>>>   * Test failures at windows are intermittent.  It is a known issue since
>>> the last few versions
>>>   * No issue at my local redhat 7/java7 build
>>>   * I am seeing test failures at
>>> https://builds.apache.org/view/All/job/maven-wagon/1323/    starting with
>>> your change for WAGON-472. Dont think it is related, could be from build
>>> env
>>>
>>
>> This is build env. I have tested Wagon on Windows and FreeBSD before any
>> patching. Windows was fine, FreeBSD failed for those two cases. It also
>> passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I
>> have good news: I have been working on the unit tests in genereal the last
>> two days by migrating to Jetty 8 (last Java 1.6 supported) version and
>> found several bugs in Wagon HTTP Provider and the unit test setup itself. I
>> will report them shortly.
>>
>> Michael
>>
>>
>> On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov <[hidden email]>
>>> wrote:
>>>
>>> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>>>>
>>>> Hi,
>>>>>
>>>>> We have fixed 18 issues:
>>>>> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>>>> ectId=12318122&version=12333396
>>>>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>>>>> ectId=12318122&version=12333396>*
>>>>>
>>>>> There are still issues left in JIRA:
>>>>> *<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>>>> 20created%20DESC%2C%20priority%20DESC
>>>>> <<a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%">https://issues.apache.org/jira/issues/?jql=project%20%3D%
>>>>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>>>>> 20created%20DESC%2C%20priority%20DESC>*
>>>>>
>>>>> Staging repository:
>>>>> https://repository.apache.org/content/repositories/maven-1313
>>>>> https://repository.apache.org/content/repositories/maven-
>>>>> 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip
>>>>>
>>>>> Source release checksum(s):
>>>>> wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
>>>>> 00c58abfa5
>>>>>
>>>>> Staging site:
>>>>> *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
>>>>> <http://maven.apache.org/components/wagon-archives/wagon-LATEST/>*
>>>>>
>>>>> Guide to testing staged releases:
>>>>> https://maven.apache.org/guides/development/guide-testing-releases.html
>>>>> <https://maven.apache.org/guides/development/guide-testing-
>>>>> releases.html>
>>>>> Vote open for 72H + 48H to accomodate for holidays
>>>>>
>>>>>
>>>> +1
>>>>
>>>> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
>>>> on non-Windows, here on my FreeBSD machine as well as on our Jenkins
>>>> Ubuntu
>>>> slave. It should probably investigated for the 3.0 release.
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
In reply to this post by Dan Tran
Am 2016-12-25 um 19:51 schrieb Dan Tran:
> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
> same test failure??

As you have already noticed, the branch is up. It is preliminary work,
but should be quite complete.

The runTestSecuredGet() and friends failures might be due to:

> [main] INFO org.eclipse.jetty.server.handler.ContextHandler - stopped o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Projekte/maven-wagon/wagon-providers/wagon-http/target/test-output/}
> [qtp1948835427-2572] WARN org.eclipse.jetty.server.Response - Committed before 500 org.eclipse.jetty.io.EofException
> [qtp1948835427-2572] WARN org.eclipse.jetty.server.AbstractHttpConnection - /test-secured-resource
> java.lang.IllegalStateException: Committed
>         at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1145)
>         at org.eclipse.jetty.server.Response.sendError(Response.java:315)
>         at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566)
>         at org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler.handle(HttpWagonTestCase.java:2148)
>         at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>         at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>         at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>         at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>         at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>         at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>         at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>         at org.eclipse.jetty.server.Server.handle(Server.java:370)
>         at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>         at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>         at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>         at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>         at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>         at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>         at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>         at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>         at org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:670)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>         at java.lang.Thread.run(Thread.java:745)

I have them sporadically. According to Stackoverflow, the client closes
the connection in flight, the server does not expect that and fails.
Though the Java code is the same, it might be related to different
socket approaches in Windows and Linux/FreeBSD.

Jetty's BasicAuthenticator sends 401 which fails with IOExeption,
SecurityHandler catches and sends 500 which fails again. This is clearly
a socket issue for me.
This requires tweaking the HttpClientConnectionManager.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
In reply to this post by Dan Tran
Hi Dan,

Am 2016-12-25 um 19:51 schrieb Dan Tran:
> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
> same test failure??
>
> Do you think we should cancel the vote and wait for your fix?

I was finally able to complete my coding and testings. After several
hours of testing and debugging, I've found the reasons why several tests
were failing sporadically, some were bad test conditions
(testSecuredGet(), testSecuredGetToStream()) and some rooted in bugs in
HttpWagon. I'll go in detail:

1. Flaky testSecuredGet(ToStream):
This failed once in a while due to race conditions between Jetty's qtp
threads and the main thread running the tests and the assertions. Jetty
did not fully complete the process chain while Surefire continued to
verify the result. This yielded to: expected <2> requests found <1> and
so forth. I added a simple sleep() and it did work. I avoided to have
complex sync code with CountDownLatch or alike. Some logging added to
the code shows the following in Surefire's XML output:

> <failure message="not 2 security handler use [HandlerRequestResponse{method=&apos;GET&apos;, responseCode=401, requestUri=&apos;/test-secured-resource&apos;}] expected:&lt;2&gt; but was:&lt;1&gt;" type="junit.framework.AssertionFailedError"><![CDATA[junit.framework.AssertionFailedError: not 2 security handler use [HandlerRequestResponse{method='GET', responseCode=401, requestUri='/test-secured-resource'}] expected:<2> but was:<1>
>         at junit.framework.Assert.fail(Assert.java:57)
>         at junit.framework.Assert.failNotEquals(Assert.java:329)
>         at junit.framework.Assert.assertEquals(Assert.java:78)
>         at junit.framework.Assert.assertEquals(Assert.java:234)
>         at junit.framework.TestCase.assertEquals(TestCase.java:401)
>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthentication(HttpWagonTestCase.java:1910)
>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthenticationGet(HttpWagonTestCase.java:1891)
>         at org.apache.maven.wagon.http.HttpWagonTestCase.runTestSecuredGetToStream(HttpWagonTestCase.java:1409)
>         at org.apache.maven.wagon.http.HttpWagonTestCase.testSecuredGetToStream(HttpWagonTestCase.java:1374)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at junit.framework.TestCase.runTest(TestCase.java:176)
>         at junit.framework.TestCase.runBare(TestCase.java:141)
>         at junit.framework.TestResult$1.protect(TestResult.java:122)
>         at junit.framework.TestResult.runProtected(TestResult.java:142)
>         at junit.framework.TestResult.run(TestResult.java:125)
>         at junit.framework.TestCase.run(TestCase.java:129)
>         at junit.framework.TestSuite.runTest(TestSuite.java:255)
>         at junit.framework.TestSuite.run(TestSuite.java:250)
>         at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>         at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> ]]></failure>

now the logging:

> <system-err><![CDATA[[main] INFO org.eclipse.jetty.server.Server - jetty-8.1.22.v20160922
> [main] INFO org.eclipse.jetty.server.AbstractConnector - Started SelectChannelConnector@0.0.0.0:45658
> [main] DEBUG org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected: compatibility
> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection request: [route: {}->http://localhost:45658][total kept alive: 39; route allocated: 0 of 20; total allocated: 39 of 40]
> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection leased: [id: 86][route: {}->http://localhost:45658][total kept alive: 39; route allocated: 1 of 20; total allocated: 40 of 40]
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Opening connection {}->http://localhost:45658
> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connecting to localhost/127.0.0.1:45658
> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connection established 127.0.0.1:45659<->127.0.0.1:45658
> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-86: set socket timeout to 1800000
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing request GET /test-secured-resource HTTP/1.1
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth state: UNCHALLENGED
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth state: UNCHALLENGED
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET /test-secured-resource HTTP/1.1
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store: no-store
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma: no-cache
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Accept-Encoding: gzip
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host: localhost:45658
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.7.0_111)
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 401 Unauthorized
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << WWW-Authenticate: basic realm="MyRealm"
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Cache-Control: must-revalidate,no-cache,no-store
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Content-Type: text/html;charset=ISO-8859-1
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Content-Length: 1311
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server: Jetty(8.1.22.v20160922)
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection can be kept alive indefinitely
> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Authentication required
> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - localhost:45658 requested authentication
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, Digest, Basic]
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Negotiate authentication scheme not available
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Kerberos authentication scheme not available
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for NTLM authentication scheme not available
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for Digest authentication scheme not available
> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Selected authentication options: [BASIC [complete=true]]
> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-86: set socket timeout to 1800000
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing request GET /test-secured-resource HTTP/1.1
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth state: CHALLENGED
> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Generating response to an authentication challenge using basic scheme
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth state: UNCHALLENGED
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET /test-secured-resource HTTP/1.1
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store: no-store
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma: no-cache
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Accept-Encoding: gzip
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host: localhost:45658
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.7.0_111)
> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Authorization: Basic dXNlcjpzZWNyZXQ=
> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167 (count 1): handled GET /test-secured-resource with status 401
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 200 OK
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Accept-Ranges: bytes
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Content-Length: 10
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Last-Modified: Mon, 26 Dec 2016 23:07:55 GMT
> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server: Jetty(8.1.22.v20160922)
> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection can be kept alive indefinitely
> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Authentication succeeded
> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy - Caching 'basic' auth scheme for http://localhost:45658
> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection [id: 86][route: {}->http://localhost:45658] can be kept alive indefinitely
> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection released: [id: 86][route: {}->http://localhost:45658][total kept alive: 40; route allocated: 1 of 20; total allocated: 40 of 40]
> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167 (1)
> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167 (count 2): handled GET /test-secured-resource with status 200
> [main] INFO org.eclipse.jetty.server.handler.ContextHandler - stopped o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Projekte/maven-wagon/wagon-providers/wagon-http/target/test-output/}
> ]]></system-err>

now take a look at TestSecurityHandler output. I added it after
super.handle() called by Jetty. As you can see,
"org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
(1)" is printed where the assertions kick in, after Wagon has completed,
but the second request is handled afterwards. A traditional race condition.

2. Bugs found:
Several auth tests fail for no reason too once in a while. Logging
showed me that HttpClient simply did not send any Basic data, regardless
if preemptive or after a roundtrip. The basic problem was that
non-threadsafe classes have been used in a non-threadsafe manner as well
as auth caches have not beed released properly, and preemptive auth was
configured incorrectly. After fixing the issues one by one, the tests
never failed again.

I have tested the code on three platforms and six JDK versions tens of
times, they never failed again. After we have resolved your
HugeDowloadTest issue and no one else objects, I'd like to merge this
into master and like you to reroll 2.11 with those changes.

Meanwhile, I'll test this branch with Maven Core IT Suite too.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Dan Tran
i still see the same timeout error on the jetty8 branch. No issue at master

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork -> [Help
1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)



It is your call now. since I cant release it

-Dan

On Tue, Dec 27, 2016 at 5:05 PM, Michael Osipov <[hidden email]> wrote:

> Hi Dan,
>
> Am 2016-12-25 um 19:51 schrieb Dan Tran:
>
>> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
>> same test failure??
>>
>> Do you think we should cancel the vote and wait for your fix?
>>
>
> I was finally able to complete my coding and testings. After several hours
> of testing and debugging, I've found the reasons why several tests were
> failing sporadically, some were bad test conditions (testSecuredGet(),
> testSecuredGetToStream()) and some rooted in bugs in HttpWagon. I'll go in
> detail:
>
> 1. Flaky testSecuredGet(ToStream):
> This failed once in a while due to race conditions between Jetty's qtp
> threads and the main thread running the tests and the assertions. Jetty did
> not fully complete the process chain while Surefire continued to verify the
> result. This yielded to: expected <2> requests found <1> and so forth. I
> added a simple sleep() and it did work. I avoided to have complex sync code
> with CountDownLatch or alike. Some logging added to the code shows the
> following in Surefire's XML output:
>
> <failure message="not 2 security handler use [HandlerRequestResponse{method=&apos;GET&apos;,
>> responseCode=401, requestUri=&apos;/test-secured-resource&apos;}]
>> expected:&lt;2&gt; but was:&lt;1&gt;" type="junit.framework.Assertio
>> nFailedError"><![CDATA[junit.framework.AssertionFailedError: not 2
>> security handler use [HandlerRequestResponse{method='GET',
>> responseCode=401, requestUri='/test-secured-resource'}] expected:<2> but
>> was:<1>
>>         at junit.framework.Assert.fail(Assert.java:57)
>>         at junit.framework.Assert.failNotEquals(Assert.java:329)
>>         at junit.framework.Assert.assertEquals(Assert.java:78)
>>         at junit.framework.Assert.assertEquals(Assert.java:234)
>>         at junit.framework.TestCase.assertEquals(TestCase.java:401)
>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptive
>> Authentication(HttpWagonTestCase.java:1910)
>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptive
>> AuthenticationGet(HttpWagonTestCase.java:1891)
>>         at org.apache.maven.wagon.http.HttpWagonTestCase.runTestSecured
>> GetToStream(HttpWagonTestCase.java:1409)
>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testSecuredGet
>> ToStream(HttpWagonTestCase.java:1374)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:57)
>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>         at junit.framework.TestCase.runTest(TestCase.java:176)
>>         at junit.framework.TestCase.runBare(TestCase.java:141)
>>         at junit.framework.TestResult$1.protect(TestResult.java:122)
>>         at junit.framework.TestResult.runProtected(TestResult.java:142)
>>         at junit.framework.TestResult.run(TestResult.java:125)
>>         at junit.framework.TestCase.run(TestCase.java:129)
>>         at junit.framework.TestSuite.runTest(TestSuite.java:255)
>>         at junit.framework.TestSuite.run(TestSuite.java:250)
>>         at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
>> ssRunner.java:84)
>>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUni
>> t4Provider.java:283)
>>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithR
>> erun(JUnit4Provider.java:173)
>>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestS
>> et(JUnit4Provider.java:153)
>>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit
>> 4Provider.java:128)
>>         at org.apache.maven.surefire.booter.ForkedBooter.invokeProvider
>> InSameClassLoader(ForkedBooter.java:203)
>>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInPro
>> cess(ForkedBooter.java:155)
>>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBoo
>> ter.java:103)
>> ]]></failure>
>>
>
> now the logging:
>
> <system-err><![CDATA[[main] INFO org.eclipse.jetty.server.Server -
>> jetty-8.1.22.v20160922
>> [main] INFO org.eclipse.jetty.server.AbstractConnector - Started
>> SelectChannelConnector@0.0.0.0:45658
>> [main] DEBUG org.apache.http.client.protocol.RequestAddCookies -
>> CookieSpec selected: compatibility
>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>> - Connection request: [route: {}->http://localhost:45658][total kept
>> alive: 39; route allocated: 0 of 20; total allocated: 39 of 40]
>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>> - Connection leased: [id: 86][route: {}->http://localhost:45658][total
>> kept alive: 39; route allocated: 1 of 20; total allocated: 40 of 40]
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Opening
>> connection {}->http://localhost:45658
>> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator
>> - Connecting to localhost/127.0.0.1:45658
>> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator
>> - Connection established 127.0.0.1:45659<->127.0.0.1:45658
>> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection
>> - http-outgoing-86: set socket timeout to 1800000
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing
>> request GET /test-secured-resource HTTP/1.1
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth
>> state: UNCHALLENGED
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
>> state: UNCHALLENGED
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET
>> /test-secured-resource HTTP/1.1
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control:
>> no-cache
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>> no-store
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma:
>> no-cache
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>> Accept-Encoding: gzip
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host:
>> localhost:45658
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection:
>> Keep-Alive
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>> Apache-HttpClient/4.5.2 (Java/1.7.0_111)
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 401
>> Unauthorized
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>> WWW-Authenticate: basic realm="MyRealm"
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Cache-Control:
>> must-revalidate,no-cache,no-store
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Content-Type:
>> text/html;charset=ISO-8859-1
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>> Content-Length: 1311
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>> Jetty(8.1.22.v20160922)
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection
>> can be kept alive indefinitely
>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>> Authentication required
>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>> localhost:45658 requested authentication
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Authentication schemes in the order of preference: [Negotiate, Kerberos,
>> NTLM, Digest, Basic]
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Challenge for Negotiate authentication scheme not available
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Challenge for Kerberos authentication scheme not available
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Challenge for NTLM authentication scheme not available
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Challenge for Digest authentication scheme not available
>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Selected
>> authentication options: [BASIC [complete=true]]
>> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection
>> - http-outgoing-86: set socket timeout to 1800000
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing
>> request GET /test-secured-resource HTTP/1.1
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth
>> state: CHALLENGED
>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Generating
>> response to an authentication challenge using basic scheme
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
>> state: UNCHALLENGED
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET
>> /test-secured-resource HTTP/1.1
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control:
>> no-cache
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>> no-store
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma:
>> no-cache
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>> Accept-Encoding: gzip
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host:
>> localhost:45658
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection:
>> Keep-Alive
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>> Apache-HttpClient/4.5.2 (Java/1.7.0_111)
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Authorization:
>> Basic dXNlcjpzZWNyZXQ=
>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>> (count 1): handled GET /test-secured-resource with status 401
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 200 OK
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Accept-Ranges:
>> bytes
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>> Content-Length: 10
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Last-Modified:
>> Mon, 26 Dec 2016 23:07:55 GMT
>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>> Jetty(8.1.22.v20160922)
>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection
>> can be kept alive indefinitely
>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>> Authentication succeeded
>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>> Caching 'basic' auth scheme for http://localhost:45658
>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>> - Connection [id: 86][route: {}->http://localhost:45658] can be kept
>> alive indefinitely
>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>> - Connection released: [id: 86][route: {}->http://localhost:45658][total
>> kept alive: 40; route allocated: 1 of 20; total allocated: 40 of 40]
>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>> (1)
>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>> (count 2): handled GET /test-secured-resource with status 200
>> [main] INFO org.eclipse.jetty.server.handler.ContextHandler - stopped
>> o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Proje
>> kte/maven-wagon/wagon-providers/wagon-http/target/test-output/}
>> ]]></system-err>
>>
>
> now take a look at TestSecurityHandler output. I added it after
> super.handle() called by Jetty. As you can see,
> "org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> (1)" is printed where the assertions kick in, after Wagon has completed,
> but the second request is handled afterwards. A traditional race condition.
>
> 2. Bugs found:
> Several auth tests fail for no reason too once in a while. Logging showed
> me that HttpClient simply did not send any Basic data, regardless if
> preemptive or after a roundtrip. The basic problem was that non-threadsafe
> classes have been used in a non-threadsafe manner as well as auth caches
> have not beed released properly, and preemptive auth was configured
> incorrectly. After fixing the issues one by one, the tests never failed
> again.
>
> I have tested the code on three platforms and six JDK versions tens of
> times, they never failed again. After we have resolved your HugeDowloadTest
> issue and no one else objects, I'd like to merge this into master and like
> you to reroll 2.11 with those changes.
>
> Meanwhile, I'll test this branch with Maven Core IT Suite too.
>
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

michaelo
Am 2016-12-28 um 06:05 schrieb Dan Tran:

> i still see the same timeout error on the jetty8 branch. No issue at master
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (default-test) on project wagon-http: There was a timeout or other
> error in the fork -> [Help
> 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (default-test) on project wagon-http: There was a timeout or other
> error in the fork
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>
>

I still would like to see your Surefire XML. Please provide! Can you
raise forkedProcessTimeoutInSeconds?
This could also be a race condition where one thread does not wait for
another. Please also note:
https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3C81e68f7b-b68f-ce5d-2529-12d604d42c98%40apache.org%3E

Can you set up a job on Jenkins for this branch? I'd like to see wether
the Ubuntu slave fails too.

 > It is your call now. since I cant release it

Do you want me to roll the release?

> On Tue, Dec 27, 2016 at 5:05 PM, Michael Osipov <[hidden email]> wrote:
>
>> Hi Dan,
>>
>> Am 2016-12-25 um 19:51 schrieb Dan Tran:
>>
>>> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
>>> same test failure??
>>>
>>> Do you think we should cancel the vote and wait for your fix?
>>>
>>
>> I was finally able to complete my coding and testings. After several hours
>> of testing and debugging, I've found the reasons why several tests were
>> failing sporadically, some were bad test conditions (testSecuredGet(),
>> testSecuredGetToStream()) and some rooted in bugs in HttpWagon. I'll go in
>> detail:
>>
>> 1. Flaky testSecuredGet(ToStream):
>> This failed once in a while due to race conditions between Jetty's qtp
>> threads and the main thread running the tests and the assertions. Jetty did
>> not fully complete the process chain while Surefire continued to verify the
>> result. This yielded to: expected <2> requests found <1> and so forth. I
>> added a simple sleep() and it did work. I avoided to have complex sync code
>> with CountDownLatch or alike. Some logging added to the code shows the
>> following in Surefire's XML output:
>>
>> <failure message="not 2 security handler use [HandlerRequestResponse{method=&apos;GET&apos;,
>>> responseCode=401, requestUri=&apos;/test-secured-resource&apos;}]
>>> expected:&lt;2&gt; but was:&lt;1&gt;" type="junit.framework.Assertio
>>> nFailedError"><![CDATA[junit.framework.AssertionFailedError: not 2
>>> security handler use [HandlerRequestResponse{method='GET',
>>> responseCode=401, requestUri='/test-secured-resource'}] expected:<2> but
>>> was:<1>
>>>         at junit.framework.Assert.fail(Assert.java:57)
>>>         at junit.framework.Assert.failNotEquals(Assert.java:329)
>>>         at junit.framework.Assert.assertEquals(Assert.java:78)
>>>         at junit.framework.Assert.assertEquals(Assert.java:234)
>>>         at junit.framework.TestCase.assertEquals(TestCase.java:401)
>>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptive
>>> Authentication(HttpWagonTestCase.java:1910)
>>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptive
>>> AuthenticationGet(HttpWagonTestCase.java:1891)
>>>         at org.apache.maven.wagon.http.HttpWagonTestCase.runTestSecured
>>> GetToStream(HttpWagonTestCase.java:1409)
>>>         at org.apache.maven.wagon.http.HttpWagonTestCase.testSecuredGet
>>> ToStream(HttpWagonTestCase.java:1374)
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:57)
>>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>>         at junit.framework.TestCase.runTest(TestCase.java:176)
>>>         at junit.framework.TestCase.runBare(TestCase.java:141)
>>>         at junit.framework.TestResult$1.protect(TestResult.java:122)
>>>         at junit.framework.TestResult.runProtected(TestResult.java:142)
>>>         at junit.framework.TestResult.run(TestResult.java:125)
>>>         at junit.framework.TestCase.run(TestCase.java:129)
>>>         at junit.framework.TestSuite.runTest(TestSuite.java:255)
>>>         at junit.framework.TestSuite.run(TestSuite.java:250)
>>>         at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38Cla
>>> ssRunner.java:84)
>>>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUni
>>> t4Provider.java:283)
>>>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithR
>>> erun(JUnit4Provider.java:173)
>>>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestS
>>> et(JUnit4Provider.java:153)
>>>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit
>>> 4Provider.java:128)
>>>         at org.apache.maven.surefire.booter.ForkedBooter.invokeProvider
>>> InSameClassLoader(ForkedBooter.java:203)
>>>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInPro
>>> cess(ForkedBooter.java:155)
>>>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBoo
>>> ter.java:103)
>>> ]]></failure>
>>>
>>
>> now the logging:
>>
>> <system-err><![CDATA[[main] INFO org.eclipse.jetty.server.Server -
>>> jetty-8.1.22.v20160922
>>> [main] INFO org.eclipse.jetty.server.AbstractConnector - Started
>>> SelectChannelConnector@0.0.0.0:45658
>>> [main] DEBUG org.apache.http.client.protocol.RequestAddCookies -
>>> CookieSpec selected: compatibility
>>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>>> - Connection request: [route: {}->http://localhost:45658][total kept
>>> alive: 39; route allocated: 0 of 20; total allocated: 39 of 40]
>>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>>> - Connection leased: [id: 86][route: {}->http://localhost:45658][total
>>> kept alive: 39; route allocated: 1 of 20; total allocated: 40 of 40]
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Opening
>>> connection {}->http://localhost:45658
>>> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator
>>> - Connecting to localhost/127.0.0.1:45658
>>> [main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator
>>> - Connection established 127.0.0.1:45659<->127.0.0.1:45658
>>> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection
>>> - http-outgoing-86: set socket timeout to 1800000
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing
>>> request GET /test-secured-resource HTTP/1.1
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth
>>> state: UNCHALLENGED
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
>>> state: UNCHALLENGED
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET
>>> /test-secured-resource HTTP/1.1
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control:
>>> no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>>> no-store
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma:
>>> no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Accept-Encoding: gzip
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host:
>>> localhost:45658
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection:
>>> Keep-Alive
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>>> Apache-HttpClient/4.5.2 (Java/1.7.0_111)
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 401
>>> Unauthorized
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>>> WWW-Authenticate: basic realm="MyRealm"
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Cache-Control:
>>> must-revalidate,no-cache,no-store
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Content-Type:
>>> text/html;charset=ISO-8859-1
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>>> Content-Length: 1311
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>>> Jetty(8.1.22.v20160922)
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection
>>> can be kept alive indefinitely
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>>> Authentication required
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>>> localhost:45658 requested authentication
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Authentication schemes in the order of preference: [Negotiate, Kerberos,
>>> NTLM, Digest, Basic]
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Challenge for Negotiate authentication scheme not available
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Challenge for Kerberos authentication scheme not available
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Challenge for NTLM authentication scheme not available
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Challenge for Digest authentication scheme not available
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Selected
>>> authentication options: [BASIC [complete=true]]
>>> [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection
>>> - http-outgoing-86: set socket timeout to 1800000
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing
>>> request GET /test-secured-resource HTTP/1.1
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth
>>> state: CHALLENGED
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator - Generating
>>> response to an authentication challenge using basic scheme
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
>>> state: UNCHALLENGED
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> GET
>>> /test-secured-resource HTTP/1.1
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-control:
>>> no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>>> no-store
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Pragma:
>>> no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Expires: 0
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Accept-Encoding: gzip
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Host:
>>> localhost:45658
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Connection:
>>> Keep-Alive
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>>> Apache-HttpClient/4.5.2 (Java/1.7.0_111)
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Authorization:
>>> Basic dXNlcjpzZWNyZXQ=
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (count 1): handled GET /test-secured-resource with status 401
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 200 OK
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Accept-Ranges:
>>> bytes
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>>> Content-Length: 10
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Last-Modified:
>>> Mon, 26 Dec 2016 23:07:55 GMT
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>>> Jetty(8.1.22.v20160922)
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection
>>> can be kept alive indefinitely
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>>> Authentication succeeded
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Caching 'basic' auth scheme for http://localhost:45658
>>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>>> - Connection [id: 86][route: {}->http://localhost:45658] can be kept
>>> alive indefinitely
>>> [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager
>>> - Connection released: [id: 86][route: {}->http://localhost:45658][total
>>> kept alive: 40; route allocated: 1 of 20; total allocated: 40 of 40]
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (1)
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (count 2): handled GET /test-secured-resource with status 200
>>> [main] INFO org.eclipse.jetty.server.handler.ContextHandler - stopped
>>> o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Proje
>>> kte/maven-wagon/wagon-providers/wagon-http/target/test-output/}
>>> ]]></system-err>
>>>
>>
>> now take a look at TestSecurityHandler output. I added it after
>> super.handle() called by Jetty. As you can see,
>> "org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>> (1)" is printed where the assertions kick in, after Wagon has completed,
>> but the second request is handled afterwards. A traditional race condition.
>>
>> 2. Bugs found:
>> Several auth tests fail for no reason too once in a while. Logging showed
>> me that HttpClient simply did not send any Basic data, regardless if
>> preemptive or after a roundtrip. The basic problem was that non-threadsafe
>> classes have been used in a non-threadsafe manner as well as auth caches
>> have not beed released properly, and preemptive auth was configured
>> incorrectly. After fixing the issues one by one, the tests never failed
>> again.
>>
>> I have tested the code on three platforms and six JDK versions tens of
>> times, they never failed again. After we have resolved your HugeDowloadTest
>> issue and no one else objects, I'd like to merge this into master and like
>> you to reroll 2.11 with those changes.
>>
>> Meanwhile, I'll test this branch with Maven Core IT Suite too.
>>
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Hervé BOUTEMY
In reply to this post by michaelo
the branch runs without issue on my machine now:
mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux

the proposed release was consistently failing on HugeFileDownloadTest

Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure:
testCompile (default-testCompile) on project wagon-file

Using "-ldm" makes the build happy again, until a Surefire run fails with a
timeout...

Regards,

Hervé

Le mercredi 28 décembre 2016, 02:05:23 CET Michael Osipov a écrit :

> Hi Dan,
>
> Am 2016-12-25 um 19:51 schrieb Dan Tran:
> > Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
> > same test failure??
> >
> > Do you think we should cancel the vote and wait for your fix?
>
> I was finally able to complete my coding and testings. After several
> hours of testing and debugging, I've found the reasons why several tests
> were failing sporadically, some were bad test conditions
> (testSecuredGet(), testSecuredGetToStream()) and some rooted in bugs in
> HttpWagon. I'll go in detail:
>
> 1. Flaky testSecuredGet(ToStream):
> This failed once in a while due to race conditions between Jetty's qtp
> threads and the main thread running the tests and the assertions. Jetty
> did not fully complete the process chain while Surefire continued to
> verify the result. This yielded to: expected <2> requests found <1> and
> so forth. I added a simple sleep() and it did work. I avoided to have
> complex sync code with CountDownLatch or alike. Some logging added to
>
> the code shows the following in Surefire's XML output:
> > <failure message="not 2 security handler use
> > [HandlerRequestResponse{method=&apos;GET&apos;, responseCode=401,
> > requestUri=&apos;/test-secured-resource&apos;}] expected:&lt;2&gt; but
> > was:&lt;1&gt;"
> > type="junit.framework.AssertionFailedError"><![CDATA[junit.framework.Asse
> > rtionFailedError: not 2 security handler use
> > [HandlerRequestResponse{method='GET', responseCode=401,
> > requestUri='/test-secured-resource'}] expected:<2> but was:<1>>
> >         at junit.framework.Assert.fail(Assert.java:57)
> >         at junit.framework.Assert.failNotEquals(Assert.java:329)
> >         at junit.framework.Assert.assertEquals(Assert.java:78)
> >         at junit.framework.Assert.assertEquals(Assert.java:234)
> >         at junit.framework.TestCase.assertEquals(TestCase.java:401)
> >         at
> >         org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthe
> >         ntication(HttpWagonTestCase.java:1910) at
> >         org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthe
> >         nticationGet(HttpWagonTestCase.java:1891) at
> >         org.apache.maven.wagon.http.HttpWagonTestCase.runTestSecuredGetTo
> >         Stream(HttpWagonTestCase.java:1409) at
> >         org.apache.maven.wagon.http.HttpWagonTestCase.testSecuredGetToStr
> >         eam(HttpWagonTestCase.java:1374) at
> >         sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         at
> >         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI
> >         mpl.java:57) at
> >         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
> >         ccessorImpl.java:43) at
> >         java.lang.reflect.Method.invoke(Method.java:606)
> >         at junit.framework.TestCase.runTest(TestCase.java:176)
> >         at junit.framework.TestCase.runBare(TestCase.java:141)
> >         at junit.framework.TestResult$1.protect(TestResult.java:122)
> >         at junit.framework.TestResult.runProtected(TestResult.java:142)
> >         at junit.framework.TestResult.run(TestResult.java:125)
> >         at junit.framework.TestCase.run(TestCase.java:129)
> >         at junit.framework.TestSuite.runTest(TestSuite.java:255)
> >         at junit.framework.TestSuite.run(TestSuite.java:250)
> >         at
> >         org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRun
> >         ner.java:84) at
> >         org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Pro
> >         vider.java:283) at
> >         org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(
> >         JUnit4Provider.java:173) at
> >         org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JU
> >         nit4Provider.java:153) at
> >         org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Prov
> >         ider.java:128) at
> >         org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSam
> >         eClassLoader(ForkedBooter.java:203) at
> >         org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
> >         ForkedBooter.java:155) at
> >         org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.j
> >         ava:103)>
> > ]]></failure>
>
> now the logging:
> > <system-err><![CDATA[[main] INFO org.eclipse.jetty.server.Server -
> > jetty-8.1.22.v20160922 [main] INFO
> > org.eclipse.jetty.server.AbstractConnector - Started
> > SelectChannelConnector@0.0.0.0:45658 [main] DEBUG
> > org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected:
> > compatibility [main] DEBUG
> > org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
> > request: [route: {}->http://localhost:45658][total kept alive: 39; route
> > allocated: 0 of 20; total allocated: 39 of 40] [main] DEBUG
> > org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
> > leased: [id: 86][route: {}->http://localhost:45658][total kept alive: 39;
> > route allocated: 1 of 20; total allocated: 40 of 40] [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Opening connection
> > {}->http://localhost:45658 [main] DEBUG
> > org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
> > Connecting to localhost/127.0.0.1:45658 [main] DEBUG
> > org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
> > Connection established 127.0.0.1:45659<->127.0.0.1:45658 [main] DEBUG
> > org.apache.http.impl.conn.DefaultManagedHttpClientConnection -
> > http-outgoing-86: set socket timeout to 1800000 [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Executing request GET
> > /test-secured-resource HTTP/1.1 [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Target auth state:
> > UNCHALLENGED [main] DEBUG org.apache.http.impl.execchain.MainClientExec -
> > Proxy auth state: UNCHALLENGED [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 >> GET /test-secured-resource HTTP/1.1 [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
> > no-store [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
> > Pragma: no-cache [main] DEBUG org.apache.http.headers - http-outgoing-86
> > >> Expires: 0 [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
> > Accept-Encoding: gzip [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 >> Host: localhost:45658 [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
> > Apache-HttpClient/4.5.2 (Java/1.7.0_111) [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 << HTTP/1.1 401 Unauthorized
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
> > WWW-Authenticate: basic realm="MyRealm" [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 << Cache-Control:
> > must-revalidate,no-cache,no-store [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 << Content-Type: text/html;charset=ISO-8859-1 [main]
> > DEBUG org.apache.http.headers - http-outgoing-86 << Content-Length: 1311
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
> > Jetty(8.1.22.v20160922) [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Connection can be kept
> > alive indefinitely [main] DEBUG
> > org.apache.http.impl.auth.HttpAuthenticator - Authentication required
> > [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
> > localhost:45658 requested authentication [main] DEBUG
> > org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication
> > schemes in the order of preference: [Negotiate, Kerberos, NTLM, Digest,
> > Basic] [main] DEBUG
> > org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
> > Negotiate authentication scheme not available [main] DEBUG
> > org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
> > Kerberos authentication scheme not available [main] DEBUG
> > org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
> > NTLM authentication scheme not available [main] DEBUG
> > org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
> > Digest authentication scheme not available [main] DEBUG
> > org.apache.http.impl.auth.HttpAuthenticator - Selected authentication
> > options: [BASIC [complete=true]] [main] DEBUG
> > org.apache.http.impl.conn.DefaultManagedHttpClientConnection -
> > http-outgoing-86: set socket timeout to 1800000 [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Executing request GET
> > /test-secured-resource HTTP/1.1 [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Target auth state:
> > CHALLENGED [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
> > Generating response to an authentication challenge using basic scheme
> > [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
> > state: UNCHALLENGED [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 >> GET /test-secured-resource HTTP/1.1 [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
> > no-store [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
> > Pragma: no-cache [main] DEBUG org.apache.http.headers - http-outgoing-86
> > >> Expires: 0 [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
> > Accept-Encoding: gzip [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 >> Host: localhost:45658 [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
> > Apache-HttpClient/4.5.2 (Java/1.7.0_111) [main] DEBUG
> > org.apache.http.headers - http-outgoing-86 >> Authorization: Basic
> > dXNlcjpzZWNyZXQ=
> > org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> > (count 1): handled GET /test-secured-resource with status 401 [main]
> > DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 200 OK
> > [main] DEBUG org.apache.http.headers - http-outgoing-86 << Accept-Ranges:
> > bytes [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
> > Content-Length: 10 [main] DEBUG org.apache.http.headers -
> > http-outgoing-86 << Last-Modified: Mon, 26 Dec 2016 23:07:55 GMT [main]
> > DEBUG org.apache.http.headers - http-outgoing-86 << Server:
> > Jetty(8.1.22.v20160922) [main] DEBUG
> > org.apache.http.impl.execchain.MainClientExec - Connection can be kept
> > alive indefinitely [main] DEBUG
> > org.apache.http.impl.auth.HttpAuthenticator - Authentication succeeded
> > [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
> > Caching 'basic' auth scheme for http://localhost:45658 [main] DEBUG
> > org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
> > [id: 86][route: {}->http://localhost:45658] can be kept alive
> > indefinitely [main] DEBUG
> > org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
> > released: [id: 86][route: {}->http://localhost:45658][total kept alive:
> > 40; route allocated: 1 of 20; total allocated: 40 of 40]
> > org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> > (1)
> > org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> > (count 2): handled GET /test-secured-resource with status 200 [main] INFO
> > org.eclipse.jetty.server.handler.ContextHandler - stopped
> > o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Projekte/maven-wag
> > on/wagon-providers/wagon-http/target/test-output/} ]]></system-err>
>
> now take a look at TestSecurityHandler output. I added it after
> super.handle() called by Jetty. As you can see,
> "org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> (1)" is printed where the assertions kick in, after Wagon has completed,
> but the second request is handled afterwards. A traditional race condition.
>
> 2. Bugs found:
> Several auth tests fail for no reason too once in a while. Logging
> showed me that HttpClient simply did not send any Basic data, regardless
> if preemptive or after a roundtrip. The basic problem was that
> non-threadsafe classes have been used in a non-threadsafe manner as well
> as auth caches have not beed released properly, and preemptive auth was
> configured incorrectly. After fixing the issues one by one, the tests
> never failed again.
>
> I have tested the code on three platforms and six JDK versions tens of
> times, they never failed again. After we have resolved your
> HugeDowloadTest issue and no one else objects, I'd like to merge this
> into master and like you to reroll 2.11 with those changes.
>
> Meanwhile, I'll test this branch with Maven Core IT Suite too.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Michael Osipov
In reply to this post by Dan Tran
Am 2016-12-28 um 06:05 schrieb Dan Tran:

> i still see the same timeout error on the jetty8 branch. No issue at master
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (default-test) on project wagon-http: There was a timeout or other
> error in the fork -> [Help
> 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (default-test) on project wagon-http: There was a timeout or other
> error in the fork
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)

I have now extended tests to other Linux distros:

Fedora 25, 64 bit:
OpenJDK 8 Update 111: pass

CentOS 7, 64 bit:
OpenJDK 8 Update 111: pass
OpenJDK 7 Update 121: pass*

*This is actually your combo which works for me, but not for you...

Additionally, I added this version to Maven 3.4.0-SNAPSHOT and ran ITs
on Windows 10, Fedora 25 and FreeBSD 10.3-RELEASE. All passed.


Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

gboue
In reply to this post by Hervé BOUTEMY
I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)
- Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
- Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK

With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I
have compilation errors in the test class FileWagonTest (both on Windows
and Ubuntu)

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8] cannot access junit.framework.TestCase
   class file for junit.framework.TestCase not found
[ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52] cannot find symbol
   symbol:   method getName()
   location: class org.apache.maven.wagon.providers.file.FileWagonTest

The JUnit dependency isn't getting pulled. This is the scenario at hand:

- wagon-file has as parent wagon-providers which has a dependency on
wagon-provider-test with scope test.
- wagon-provider-test has a compile scoped dependency on junit
(<scope>compile</scope> is explicitly written).
- wagon-provider-test has as parent wagon, which has a test scoped
dependency management on junit.

What would be the problem?

The tree displayed in the logs when building wagon-provider-test
correctly lists JUnit with scope compile:

[DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT
[DEBUG]    org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]    org.codehaus.plexus:plexus-container-default:jar:1.5.5:compile
[DEBUG]       org.codehaus.plexus:plexus-classworlds:jar:2.2.2:compile
[DEBUG]       org.apache.xbean:xbean-reflect:jar:3.4:compile
[DEBUG]          log4j:log4j:jar:1.2.12:compile
[DEBUG]          commons-logging:commons-logging-api:jar:1.1:compile
[DEBUG]       com.google.collections:google-collections:jar:1.0:compile
[DEBUG]    org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]    org.easymock:easymock:jar:3.2:compile
[DEBUG]       cglib:cglib-nodep:jar:2.2.2:compile
[DEBUG]       org.objenesis:objenesis:jar:1.3:compile
[DEBUG]    org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:compile
[DEBUG]       org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[DEBUG]    javax.servlet:javax.servlet-api:jar:3.0.1:compile
[DEBUG]    org.slf4j:slf4j-api:jar:1.7.19:compile
[DEBUG]    junit:junit:jar:4.11:compile
[DEBUG]       org.hamcrest:hamcrest-core:jar:1.3:compile

But when building wagon-file, the tree is:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]    org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]    org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]       org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]    org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]    org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]       org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]          org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]          org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG]             log4j:log4j:jar:1.2.12:test
[DEBUG]             commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]          com.google.collections:google-collections:jar:1.0:test
[DEBUG]       org.easymock:easymock:jar:3.2:test
[DEBUG]          cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]          org.objenesis:objenesis:jar:1.3:test
[DEBUG]       org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]          org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]       javax.servlet:javax.servlet-api:jar:3.0.1:test


Is the problem that, during resolving the dependencies for wagon-file,
the compiled scope JUnit dependency of the direct wagon-provider-test
dependency is getting managed to scope test (due to the parent), and
therefore that this now test-scoped dependency of wagon-provider-test
isn't retrieved transitively (because it is a test dependency of a
direct test dependency)?

Guillaume

Le 28/12/2016 à 12:00, Hervé BOUTEMY a écrit :

> the branch runs without issue on my machine now:
> mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux
>
> the proposed release was consistently failing on HugeFileDownloadTest
>
> Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure:
> testCompile (default-testCompile) on project wagon-file
>
> Using "-ldm" makes the build happy again, until a Surefire run fails with a
> timeout...
>
> Regards,
>
> Hervé
>
> Le mercredi 28 décembre 2016, 02:05:23 CET Michael Osipov a écrit :
>> Hi Dan,
>>
>> Am 2016-12-25 um 19:51 schrieb Dan Tran:
>>> Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
>>> same test failure??
>>>
>>> Do you think we should cancel the vote and wait for your fix?
>> I was finally able to complete my coding and testings. After several
>> hours of testing and debugging, I've found the reasons why several tests
>> were failing sporadically, some were bad test conditions
>> (testSecuredGet(), testSecuredGetToStream()) and some rooted in bugs in
>> HttpWagon. I'll go in detail:
>>
>> 1. Flaky testSecuredGet(ToStream):
>> This failed once in a while due to race conditions between Jetty's qtp
>> threads and the main thread running the tests and the assertions. Jetty
>> did not fully complete the process chain while Surefire continued to
>> verify the result. This yielded to: expected <2> requests found <1> and
>> so forth. I added a simple sleep() and it did work. I avoided to have
>> complex sync code with CountDownLatch or alike. Some logging added to
>>
>> the code shows the following in Surefire's XML output:
>>> <failure message="not 2 security handler use
>>> [HandlerRequestResponse{method=&apos;GET&apos;, responseCode=401,
>>> requestUri=&apos;/test-secured-resource&apos;}] expected:&lt;2&gt; but
>>> was:&lt;1&gt;"
>>> type="junit.framework.AssertionFailedError"><![CDATA[junit.framework.Asse
>>> rtionFailedError: not 2 security handler use
>>> [HandlerRequestResponse{method='GET', responseCode=401,
>>> requestUri='/test-secured-resource'}] expected:<2> but was:<1>>
>>>          at junit.framework.Assert.fail(Assert.java:57)
>>>          at junit.framework.Assert.failNotEquals(Assert.java:329)
>>>          at junit.framework.Assert.assertEquals(Assert.java:78)
>>>          at junit.framework.Assert.assertEquals(Assert.java:234)
>>>          at junit.framework.TestCase.assertEquals(TestCase.java:401)
>>>          at
>>>          org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthe
>>>          ntication(HttpWagonTestCase.java:1910) at
>>>          org.apache.maven.wagon.http.HttpWagonTestCase.testPreemptiveAuthe
>>>          nticationGet(HttpWagonTestCase.java:1891) at
>>>          org.apache.maven.wagon.http.HttpWagonTestCase.runTestSecuredGetTo
>>>          Stream(HttpWagonTestCase.java:1409) at
>>>          org.apache.maven.wagon.http.HttpWagonTestCase.testSecuredGetToStr
>>>          eam(HttpWagonTestCase.java:1374) at
>>>          sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>          at
>>>          sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI
>>>          mpl.java:57) at
>>>          sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
>>>          ccessorImpl.java:43) at
>>>          java.lang.reflect.Method.invoke(Method.java:606)
>>>          at junit.framework.TestCase.runTest(TestCase.java:176)
>>>          at junit.framework.TestCase.runBare(TestCase.java:141)
>>>          at junit.framework.TestResult$1.protect(TestResult.java:122)
>>>          at junit.framework.TestResult.runProtected(TestResult.java:142)
>>>          at junit.framework.TestResult.run(TestResult.java:125)
>>>          at junit.framework.TestCase.run(TestCase.java:129)
>>>          at junit.framework.TestSuite.runTest(TestSuite.java:255)
>>>          at junit.framework.TestSuite.run(TestSuite.java:250)
>>>          at
>>>          org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRun
>>>          ner.java:84) at
>>>          org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Pro
>>>          vider.java:283) at
>>>          org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(
>>>          JUnit4Provider.java:173) at
>>>          org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JU
>>>          nit4Provider.java:153) at
>>>          org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Prov
>>>          ider.java:128) at
>>>          org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSam
>>>          eClassLoader(ForkedBooter.java:203) at
>>>          org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
>>>          ForkedBooter.java:155) at
>>>          org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.j
>>>          ava:103)>
>>> ]]></failure>
>> now the logging:
>>> <system-err><![CDATA[[main] INFO org.eclipse.jetty.server.Server -
>>> jetty-8.1.22.v20160922 [main] INFO
>>> org.eclipse.jetty.server.AbstractConnector - Started
>>> SelectChannelConnector@0.0.0.0:45658 [main] DEBUG
>>> org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected:
>>> compatibility [main] DEBUG
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
>>> request: [route: {}->http://localhost:45658][total kept alive: 39; route
>>> allocated: 0 of 20; total allocated: 39 of 40] [main] DEBUG
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
>>> leased: [id: 86][route: {}->http://localhost:45658][total kept alive: 39;
>>> route allocated: 1 of 20; total allocated: 40 of 40] [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Opening connection
>>> {}->http://localhost:45658 [main] DEBUG
>>> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
>>> Connecting to localhost/127.0.0.1:45658 [main] DEBUG
>>> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator -
>>> Connection established 127.0.0.1:45659<->127.0.0.1:45658 [main] DEBUG
>>> org.apache.http.impl.conn.DefaultManagedHttpClientConnection -
>>> http-outgoing-86: set socket timeout to 1800000 [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Executing request GET
>>> /test-secured-resource HTTP/1.1 [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Target auth state:
>>> UNCHALLENGED [main] DEBUG org.apache.http.impl.execchain.MainClientExec -
>>> Proxy auth state: UNCHALLENGED [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 >> GET /test-secured-resource HTTP/1.1 [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>>> no-store [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Pragma: no-cache [main] DEBUG org.apache.http.headers - http-outgoing-86
>>>>> Expires: 0 [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Accept-Encoding: gzip [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 >> Host: localhost:45658 [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>>> Apache-HttpClient/4.5.2 (Java/1.7.0_111) [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 << HTTP/1.1 401 Unauthorized
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>>> WWW-Authenticate: basic realm="MyRealm" [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 << Cache-Control:
>>> must-revalidate,no-cache,no-store [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 << Content-Type: text/html;charset=ISO-8859-1 [main]
>>> DEBUG org.apache.http.headers - http-outgoing-86 << Content-Length: 1311
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>>> Jetty(8.1.22.v20160922) [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Connection can be kept
>>> alive indefinitely [main] DEBUG
>>> org.apache.http.impl.auth.HttpAuthenticator - Authentication required
>>> [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>>> localhost:45658 requested authentication [main] DEBUG
>>> org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication
>>> schemes in the order of preference: [Negotiate, Kerberos, NTLM, Digest,
>>> Basic] [main] DEBUG
>>> org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
>>> Negotiate authentication scheme not available [main] DEBUG
>>> org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
>>> Kerberos authentication scheme not available [main] DEBUG
>>> org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
>>> NTLM authentication scheme not available [main] DEBUG
>>> org.apache.http.impl.client.TargetAuthenticationStrategy - Challenge for
>>> Digest authentication scheme not available [main] DEBUG
>>> org.apache.http.impl.auth.HttpAuthenticator - Selected authentication
>>> options: [BASIC [complete=true]] [main] DEBUG
>>> org.apache.http.impl.conn.DefaultManagedHttpClientConnection -
>>> http-outgoing-86: set socket timeout to 1800000 [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Executing request GET
>>> /test-secured-resource HTTP/1.1 [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Target auth state:
>>> CHALLENGED [main] DEBUG org.apache.http.impl.auth.HttpAuthenticator -
>>> Generating response to an authentication challenge using basic scheme
>>> [main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth
>>> state: UNCHALLENGED [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 >> GET /test-secured-resource HTTP/1.1 [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 >> Cache-control: no-cache
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> Cache-store:
>>> no-store [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Pragma: no-cache [main] DEBUG org.apache.http.headers - http-outgoing-86
>>>>> Expires: 0 [main] DEBUG org.apache.http.headers - http-outgoing-86 >>
>>> Accept-Encoding: gzip [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 >> Host: localhost:45658 [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 >> Connection: Keep-Alive
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 >> User-Agent:
>>> Apache-HttpClient/4.5.2 (Java/1.7.0_111) [main] DEBUG
>>> org.apache.http.headers - http-outgoing-86 >> Authorization: Basic
>>> dXNlcjpzZWNyZXQ=
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (count 1): handled GET /test-secured-resource with status 401 [main]
>>> DEBUG org.apache.http.headers - http-outgoing-86 << HTTP/1.1 200 OK
>>> [main] DEBUG org.apache.http.headers - http-outgoing-86 << Accept-Ranges:
>>> bytes [main] DEBUG org.apache.http.headers - http-outgoing-86 <<
>>> Content-Length: 10 [main] DEBUG org.apache.http.headers -
>>> http-outgoing-86 << Last-Modified: Mon, 26 Dec 2016 23:07:55 GMT [main]
>>> DEBUG org.apache.http.headers - http-outgoing-86 << Server:
>>> Jetty(8.1.22.v20160922) [main] DEBUG
>>> org.apache.http.impl.execchain.MainClientExec - Connection can be kept
>>> alive indefinitely [main] DEBUG
>>> org.apache.http.impl.auth.HttpAuthenticator - Authentication succeeded
>>> [main] DEBUG org.apache.http.impl.client.TargetAuthenticationStrategy -
>>> Caching 'basic' auth scheme for http://localhost:45658 [main] DEBUG
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
>>> [id: 86][route: {}->http://localhost:45658] can be kept alive
>>> indefinitely [main] DEBUG
>>> org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection
>>> released: [id: 86][route: {}->http://localhost:45658][total kept alive:
>>> 40; route allocated: 1 of 20; total allocated: 40 of 40]
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (1)
>>> org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>>> (count 2): handled GET /test-secured-resource with status 200 [main] INFO
>>> org.eclipse.jetty.server.handler.ContextHandler - stopped
>>> o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Projekte/maven-wag
>>> on/wagon-providers/wagon-http/target/test-output/} ]]></system-err>
>> now take a look at TestSecurityHandler output. I added it after
>> super.handle() called by Jetty. As you can see,
>> "org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
>> (1)" is printed where the assertions kick in, after Wagon has completed,
>> but the second request is handled afterwards. A traditional race condition.
>>
>> 2. Bugs found:
>> Several auth tests fail for no reason too once in a while. Logging
>> showed me that HttpClient simply did not send any Basic data, regardless
>> if preemptive or after a roundtrip. The basic problem was that
>> non-threadsafe classes have been used in a non-threadsafe manner as well
>> as auth caches have not beed released properly, and preemptive auth was
>> configured incorrectly. After fixing the issues one by one, the tests
>> never failed again.
>>
>> I have tested the code on three platforms and six JDK versions tens of
>> times, they never failed again. After we have resolved your
>> HugeDowloadTest issue and no one else objects, I'd like to merge this
>> into master and like you to reroll 2.11 with those changes.
>>
>> Meanwhile, I'll test this branch with Maven Core IT Suite too.
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Christian Schulte
Am 12/28/16 um 21:34 schrieb Guillaume Boué:

> I have the same results as Hervé, both on Windows and Ubuntu. This is
> what I have with Maven 3.3.9:
>
> - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
> HugeFileDownloadTest (perhaps the timeout should be increased?)
> - Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
> - Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK
>
> With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I
> have compilation errors in the test class FileWagonTest (both on Windows
> and Ubuntu)
>
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8] cannot access junit.framework.TestCase
>    class file for junit.framework.TestCase not found
> [ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52] cannot find symbol
>    symbol:   method getName()
>    location: class org.apache.maven.wagon.providers.file.FileWagonTest
>
> The JUnit dependency isn't getting pulled. This is the scenario at hand:
>
> - wagon-file has as parent wagon-providers which has a dependency on
> wagon-provider-test with scope test.
> - wagon-provider-test has a compile scoped dependency on junit
> (<scope>compile</scope> is explicitly written).
> - wagon-provider-test has as parent wagon, which has a test scoped
> dependency management on junit.
>
> What would be the problem?

Overriding the dependency management is only possible in the direct
dependencies (in the POM). When resolving a dependency, those overrides
are beeing ignored and the management gets applied. That's always been
that way. If your test classes need junit, you should declare junit in
the POM and not rely on it to be there transitively. The dependency
plugin's analyze goal would warn about this for the main artifact
(src/main) but not for the test artifact (src/test).



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

gboue

Le 28/12/2016 à 21:49, Christian Schulte a écrit :

> Am 12/28/16 um 21:34 schrieb Guillaume Boué:
>> I have the same results as Hervé, both on Windows and Ubuntu. This is
>> what I have with Maven 3.3.9:
>>
>> - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
>> HugeFileDownloadTest (perhaps the timeout should be increased?)
>> - Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
>> - Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK
>>
>> With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I
>> have compilation errors in the test class FileWagonTest (both on Windows
>> and Ubuntu)
>>
>> [INFO] -------------------------------------------------------------
>> [ERROR] COMPILATION ERROR :
>> [INFO] -------------------------------------------------------------
>> [ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8] cannot access junit.framework.TestCase
>>     class file for junit.framework.TestCase not found
>> [ERROR] /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52] cannot find symbol
>>     symbol:   method getName()
>>     location: class org.apache.maven.wagon.providers.file.FileWagonTest
>>
>> The JUnit dependency isn't getting pulled. This is the scenario at hand:
>>
>> - wagon-file has as parent wagon-providers which has a dependency on
>> wagon-provider-test with scope test.
>> - wagon-provider-test has a compile scoped dependency on junit
>> (<scope>compile</scope> is explicitly written).
>> - wagon-provider-test has as parent wagon, which has a test scoped
>> dependency management on junit.
>>
>> What would be the problem?
> Overriding the dependency management is only possible in the direct
> dependencies (in the POM). When resolving a dependency, those overrides
> are beeing ignored and the management gets applied. That's always been
> that way. If your test classes need junit, you should declare junit in
> the POM and not rely on it to be there transitively. The dependency
> plugin's analyze goal would warn about this for the main artifact
> (src/main) but not for the test artifact (src/test).
>

How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?

This is the tree with Maven 3.3.9:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]    org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]    org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]       org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]    org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]    org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]       org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]          org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]          org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG]             log4j:log4j:jar:1.2.12:test
[DEBUG]             commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]          com.google.collections:google-collections:jar:1.0:test
[DEBUG]       org.easymock:easymock:jar:3.2:test
[DEBUG]          cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]          org.objenesis:objenesis:jar:1.3:test
[DEBUG]       org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]          org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]       javax.servlet:javax.servlet-api:jar:3.0.1:test
[DEBUG]       junit:junit:jar:4.11:test (scope managed from compile by org.apache.maven.wagon:wagon:2.12-SNAPSHOT)
[DEBUG]          org.hamcrest:hamcrest-core:jar:1.3:test



>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Christian Schulte
Am 12/28/16 um 22:21 schrieb Guillaume Boué:
>
> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?

Because it does not come with MRESOLVER-9 fixed.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

rfscholte
Which makes me wonder if this really is a fix. Wagon can be built with a  
wide range of Maven version covering a lot of years AND the  
maven-dependency-plugin shows what you would expect: junit is available  
with test-scope.

"That's always been that way."
Well, apparently not. Maybe it was documented that way, but I expect that  
users did their dependency management which felt natural and which worked.

I'm afraid that this is exactly where Jason was warning you for.
Right now I see Wagon as a reference project for Maven 3.4.0: it should  
still work without the pom adjustments, because its original setup made  
sense.

Robert

On Wed, 28 Dec 2016 22:31:52 +0100, Christian Schulte <[hidden email]>  
wrote:

> Am 12/28/16 um 22:21 schrieb Guillaume Boué:
>>
>> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?
>
> Because it does not come with MRESOLVER-9 fixed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Christian Schulte
In reply to this post by gboue
I just pushed a fix for this. I could also have made that transitive
dependency a direct one, where it is used, and could have left the scope
management in.

"Dependency management overrides are not transitive."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Hervé BOUTEMY
In reply to this post by rfscholte
Le mercredi 28 décembre 2016, 22:50:52 CET Robert Scholte a écrit :

> Which makes me wonder if this really is a fix. Wagon can be built with a
> wide range of Maven version covering a lot of years AND the
> maven-dependency-plugin shows what you would expect: junit is available
> with test-scope.
>
> "That's always been that way."
> Well, apparently not. Maybe it was documented that way, but I expect that
> users did their dependency management which felt natural and which worked.
>
> I'm afraid that this is exactly where Jason was warning you for.
> Right now I see Wagon as a reference project for Maven 3.4.0: it should
> still work without the pom adjustments, because its original setup made
> sense.
+1

>
> Robert
>
> On Wed, 28 Dec 2016 22:31:52 +0100, Christian Schulte <[hidden email]>
>
> wrote:
> > Am 12/28/16 um 22:21 schrieb Guillaume Boué:
> >> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?
> >
> > Because it does not come with MRESOLVER-9 fixed.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Releasing Wagon 2.11

Christian Schulte
In reply to this post by rfscholte
Am 12/28/16 um 22:50 schrieb Robert Scholte:
> Which makes me wonder if this really is a fix. Wagon can be built with a  
> wide range of Maven version covering a lot of years AND the  
> maven-dependency-plugin shows what you would expect: junit is available  
> with test-scope.
>
> "That's always been that way."
> Well, apparently not. Maybe it was documented that way, but I expect that  
> users did their dependency management which felt natural and which worked.

The scope from management has been overridden in the POM and the
resolver is overriding that override with the management. That's what
makes no sense but there is no way to make the resolver not override
those overrides. It cannot detect them. And that really has always been
that way.

> Right now I see Wagon as a reference project for Maven 3.4.0: it should  
> still work without the pom adjustments, because its original setup made  
> sense.

I am not the person designing the test scope to be non-transitive. I
just made it behave that way consistently.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123