[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904522#comment-16904522
]
Tibor Digana commented on MNG-6731:
---
I hope the build will be successful
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6731/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904521#comment-16904521
]
Tibor Digana commented on MNG-6731:
---
[~michael-o]
Here is the commit
https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=shortlog;h=refs/heads/MNG-6731
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (WAGON-565) Do not skip retry on SSLException by default
[
https://issues.apache.org/jira/browse/WAGON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904518#comment-16904518
]
Oleg Kalnichevski commented on WAGON-565:
-
[~michael-o] The idea of changing the actual behavior of the default request
retrial handler with regards to SSL exceptions has already been floated at the
HC dev list. I am open to implementing the change at 5.0.x and possibly in 4.5.x
https://lists.apache.org/thread.html/35b565605a8edf4976c71495070ab4795e9007de7cde7da8aca3666c@%3Cdev.hc.apache.org%3E
However, having said that, Sun's (Oracle's) re-throwing connection reset I/O
error as {{javax.net.ssl.SSLProtocolException}} is madness.
Oleg
> Do not skip retry on SSLException by default
>
>
> Key: WAGON-565
> URL: https://issues.apache.org/jira/browse/WAGON-565
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Martin Furmanski
>Priority: Minor
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The SSL stack in Java will transform any transport error into an
> SSLException, so it is very bad to skip retries for this entire class of
> exceptions. Transport errors are probably the number one reason why retries
> are needed, so it defeats the purpose for any secure deployments using HTTPS.
> {code:java}
> Caused by: javax.net.ssl.SSLProtocolException: Connection reset
> at sun.security.ssl.Alert.createSSLException (Alert.java:126)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:321)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:264)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:259)
> at sun.security.ssl.SSLSocketImpl.handleException (SSLSocketImpl.java:1314)
> at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:839)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
> (SessionInputBufferImpl.java:137)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
> (SessionInputBufferImpl.java:153)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine
> (SessionInputBufferImpl.java:280)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:138)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:56)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse
> (AbstractMessageParser.java:259)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader
> (DefaultBHttpClientConnection.java:163)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader
> (CPoolProxy.java:157)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse
> (HttpRequestExecutor.java:273)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:125)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
> (RedirectExec.java:110)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
> (InternalHttpClient.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:958)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1117)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1094)
> at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> {code}
> I realise this is the default of the HTTP client, but changing that library
> is just too wide of a change in a patch, but for the maven wagon it sounds
> quite safe and should help many people which experience this in their
> deployments.
[jira] [Commented] (WAGON-565) Do not skip retry on SSLException by default
[
https://issues.apache.org/jira/browse/WAGON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904506#comment-16904506
]
Michael Osipov commented on WAGON-565:
--
[~olegk], what is your opinion on?
> Do not skip retry on SSLException by default
>
>
> Key: WAGON-565
> URL: https://issues.apache.org/jira/browse/WAGON-565
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Martin Furmanski
>Priority: Minor
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The SSL stack in Java will transform any transport error into an
> SSLException, so it is very bad to skip retries for this entire class of
> exceptions. Transport errors are probably the number one reason why retries
> are needed, so it defeats the purpose for any secure deployments using HTTPS.
> {code:java}
> Caused by: javax.net.ssl.SSLProtocolException: Connection reset
> at sun.security.ssl.Alert.createSSLException (Alert.java:126)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:321)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:264)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:259)
> at sun.security.ssl.SSLSocketImpl.handleException (SSLSocketImpl.java:1314)
> at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:839)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
> (SessionInputBufferImpl.java:137)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
> (SessionInputBufferImpl.java:153)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine
> (SessionInputBufferImpl.java:280)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:138)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
> (DefaultHttpResponseParser.java:56)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse
> (AbstractMessageParser.java:259)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader
> (DefaultBHttpClientConnection.java:163)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader
> (CPoolProxy.java:157)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse
> (HttpRequestExecutor.java:273)
> at
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
> (HttpRequestExecutor.java:125)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
> (MainClientExec.java:272)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
> (ProtocolExec.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
> (RetryExec.java:89)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
> (RedirectExec.java:110)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
> (InternalHttpClient.java:185)
> at
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
> (CloseableHttpClient.java:83)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
> (AbstractHttpClientWagon.java:958)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1117)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1094)
> at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> {code}
> I realise this is the default of the HTTP client, but changing that library
> is just too wide of a change in a patch, but for the maven wagon it sounds
> quite safe and should help many people which experience this in their
> deployments. The alternative is that everyone using HTTPS has to track down
> this issue and tweak their configs.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MDEP-658) Send dependency tree output to HTTP endpoints
[
https://issues.apache.org/jira/browse/MDEP-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904505#comment-16904505
]
Michael Osipov commented on MDEP-658:
-
I am rejecting this change because this is completely out of scope of this
plugin. You are free to pipe this data to {{curl}} and do what ever you want.
> Send dependency tree output to HTTP endpoints
> -
>
> Key: MDEP-658
> URL: https://issues.apache.org/jira/browse/MDEP-658
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 3.1.1
>Reporter: Esteban Cristóbal Rodríguez
>Priority: Minor
>
> Apart from writing the dependency tree on console or in a file, it would be
> useful if it could be sent over HTTP to be processed by a third-party
> service, such a ELK stack or some other tool that could process it.
> After a quick overview of the source code, it seems that the following task
> should be made to implement this enhancement:
> * Define a new property to store the service URL.
> * Apply the Strategy and Abstract Factory design patterns to implement in an
> extensible way the runtime selection of dependency tree output.
> * Define properties to store authentication data required by HTTP endpoints.
> * Implement support for HTTP authentication: basic on a first step, and
> OAuth2 later on.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904499#comment-16904499
]
Tibor Digana commented on MNG-6731:
---
[~michael-o]
Hi Michael, it is yet on my PC. I am finishing it right now. I will post an
announcement here after I have finished all.
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904497#comment-16904497
]
Michael Osipov commented on MNG-6731:
-
Where is this branch?
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MNG-6731:
--
Summary: Jetty getLocalPort() returns -1 resulting in build failures (was:
Jetty getLocalPort() returns -1 resulting build failures)
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSHADE-306) Log all duplicates, not only classes
[ https://issues.apache.org/jira/browse/MSHADE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904401#comment-16904401 ] Hudson commented on MSHADE-306: --- Build unstable in Jenkins: Maven TLP » maven-shade-plugin » master #15 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/15/ > Log all duplicates, not only classes > > > Key: MSHADE-306 > URL: https://issues.apache.org/jira/browse/MSHADE-306 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Issue to silently swallow duplicated resources is that you don't see, even in > debug, that there is a choice done by the plugin. This breaks the final app > in a lot of cases (all SPI-like cases, OSGi for the MANIFEST.MF etc...). So > let's log it as for classes. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MNG-6731) Jetty getLocalPort() returns -1 resulting build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MNG-6731:
--
Description:
We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
So I started haveing a look and I say the JavaDoc of the method
{{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
So I decided to use [2] and wait until the server is up. This was of course
wrong because the status of the server is set to {{STARTED}} immediatelly after
the method {{Server.start()}}. So therefore I was googling a little bit and I
found that Hadoop [3] had this problem too in 2010. Whole problem was with a
bug in Jetty server which is {{race condition}}. The article has a link to
Jetty's Jira with reported bug {{JETTY-748}}. According to the annoucements [4]
from Eclipse/Jetty, the bug {{JETTY-748 Prevent race close of socket by old
acceptor threads}} was fixed in the version {{jetty-7.2.1.v2010}}. So I
decided to use that version but I found that the class {{HashUserRealm}} was
deleted and there is no support and no further development of {{org.mortbay}}.
Eclipse continues with the development of Jerry 9.
All I did in this issue was to rewrite 38 integration tests to Jetty 9 API and
the fix for {{JETTY-748}} is right there.
[1]:
Error message in logs: [WARNING] Could not transfer metadata
org.apache.maven.its.mng4554/maven-metadata.xml from/to central
(http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
[2]:
{code:java}
while ( !server.isRunning() || !server.isStarted() )
{
if ( server.isFailed() )
{
fail( "Couldn't bind the server socket to a free port!" );
}
Thread.sleep( 100L );
}
{code}
[3]:
https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
[4]:
https://www.eclipse.org/lists/jetty-dev/msg00537.html
was:
We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
So I started haveing a look and I say the JavaDoc of the method
{{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
So I decided to use [2] and wait until the server is up. This was of course
wrong because the status of the server is set to `STARTED` immediatelly after
the method {{Server.start()}}. So therefore I was googling a little bit and I
found that Hadoop [3] had this problem too in 2010. Whole problem was with a
bug in Jetty server which is {{race condition}}. The article has a link to
Jetty's Jira with reported bug {{JETTY-748}}. According to the annoucements
from Eclipse/Jetty, the bug {{JETTY-748 Prevent race close of socket by old
acceptor threads}} was fixed in the version {{jetty-7.2.1.v2010}}. So I
decided to use that version but I found that the class {{HashUserRealm}} was
deleted and there is no support and no further development of {{org.mortbay}}.
Eclipse continues with the development of Jerry 9.
All I did in this issue was to rewrite 38 integration tests to Jetty 9 API and
the fix for {{JETTY-748}} is right there.
[1]:
Error message in logs: [WARNING] Could not transfer metadata
org.apache.maven.its.mng4554/maven-metadata.xml from/to central
(http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
[2]:
{code:java}
while ( !server.isRunning() || !server.isStarted() )
{
if ( server.isFailed() )
{
fail( "Couldn't bind the server socket to a free port!" );
}
Thread.sleep( 100L );
}
{code}
[3]:
https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
[4]:
https://www.eclipse.org/lists/jetty-dev/msg00537.html
> Jetty getLocalPort() returns -1 resulting build failures
>
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3]
[jira] [Updated] (MNG-6731) Jetty getLocalPort() returns -1 resulting build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MNG-6731:
--
Description:
We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
So I started haveing a look and I say the JavaDoc of the method
{{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
So I decided to use [2] and wait until the server is up. This was of course
wrong because the status of the server is set to {{STARTED}} immediatelly after
the method {{Server.start()}}. So therefore I was googling a little bit and I
found that Hadoop [3] had this problem too in 2010. Whole problem was with a
bug in Jetty server which is {{race condition}}. The article has a link to
Jetty's Jira with reported bug {{JETTY-748}}. According to the annoucements [4]
from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close of socket by old
acceptor threads}}" was fixed in the version {{jetty-7.2.1.v2010}}. So I
decided to use that version but I found that the class {{HashUserRealm}} was
deleted and there is no support and no further development of {{org.mortbay}}.
Eclipse continues with the development of Jerry 9.
All I did in this issue was to rewrite 38 integration tests to Jetty 9 API and
the fix for {{JETTY-748}} is right there.
[1]:
Error message in logs: [WARNING] Could not transfer metadata
org.apache.maven.its.mng4554/maven-metadata.xml from/to central
(http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
[2]:
{code:java}
while ( !server.isRunning() || !server.isStarted() )
{
if ( server.isFailed() )
{
fail( "Couldn't bind the server socket to a free port!" );
}
Thread.sleep( 100L );
}
{code}
[3]:
https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
[4]:
https://www.eclipse.org/lists/jetty-dev/msg00537.html
was:
We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
So I started haveing a look and I say the JavaDoc of the method
{{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
So I decided to use [2] and wait until the server is up. This was of course
wrong because the status of the server is set to {{STARTED}} immediatelly after
the method {{Server.start()}}. So therefore I was googling a little bit and I
found that Hadoop [3] had this problem too in 2010. Whole problem was with a
bug in Jetty server which is {{race condition}}. The article has a link to
Jetty's Jira with reported bug {{JETTY-748}}. According to the annoucements [4]
from Eclipse/Jetty, the bug {{JETTY-748 Prevent race close of socket by old
acceptor threads}} was fixed in the version {{jetty-7.2.1.v2010}}. So I
decided to use that version but I found that the class {{HashUserRealm}} was
deleted and there is no support and no further development of {{org.mortbay}}.
Eclipse continues with the development of Jerry 9.
All I did in this issue was to rewrite 38 integration tests to Jetty 9 API and
the fix for {{JETTY-748}} is right there.
[1]:
Error message in logs: [WARNING] Could not transfer metadata
org.apache.maven.its.mng4554/maven-metadata.xml from/to central
(http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
[2]:
{code:java}
while ( !server.isRunning() || !server.isStarted() )
{
if ( server.isFailed() )
{
fail( "Couldn't bind the server socket to a free port!" );
}
Thread.sleep( 100L );
}
{code}
[3]:
https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
[4]:
https://www.eclipse.org/lists/jetty-dev/msg00537.html
> Jetty getLocalPort() returns -1 resulting build failures
>
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.6.2, 3.6.x-candidate
>
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that
[jira] [Created] (MNG-6731) Jetty getLocalPort() returns -1 resulting build failures
Tibor Digana created MNG-6731:
-
Summary: Jetty getLocalPort() returns -1 resulting build failures
Key: MNG-6731
URL: https://issues.apache.org/jira/browse/MNG-6731
Project: Maven
Issue Type: Bug
Components: Integration Tests
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.6.2, 3.6.x-candidate
We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
So I started haveing a look and I say the JavaDoc of the method
{{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
So I decided to use [2] and wait until the server is up. This was of course
wrong because the status of the server is set to `STARTED` immediatelly after
the method {{Server.start()}}. So therefore I was googling a little bit and I
found that Hadoop [3] had this problem too in 2010. Whole problem was with a
bug in Jetty server which is {{race condition}}. The article has a link to
Jetty's Jira with reported bug {{JETTY-748}}. According to the annoucements
from Eclipse/Jetty, the bug {{JETTY-748 Prevent race close of socket by old
acceptor threads}} was fixed in the version {{jetty-7.2.1.v2010}}. So I
decided to use that version but I found that the class {{HashUserRealm}} was
deleted and there is no support and no further development of {{org.mortbay}}.
Eclipse continues with the development of Jerry 9.
All I did in this issue was to rewrite 38 integration tests to Jetty 9 API and
the fix for {{JETTY-748}} is right there.
[1]:
Error message in logs: [WARNING] Could not transfer metadata
org.apache.maven.its.mng4554/maven-metadata.xml from/to central
(http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
[2]:
{code:java}
while ( !server.isRunning() || !server.isStarted() )
{
if ( server.isFailed() )
{
fail( "Couldn't bind the server socket to a free port!" );
}
Thread.sleep( 100L );
}
{code}
[3]:
https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
[4]:
https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
