[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] ha
[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 Hadoo
[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)