Uploaded image for project: 'Slider'
  1. Slider
  2. SLIDER-878

Slider cannot support jdk 1.8 for command slider registry --getconf hbase-site --name hb1

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Slider 0.61, Slider 0.70, Slider 0.80
    • Fix Version/s: Slider 0.81
    • Component/s: client
    • Labels:
      None
    • Environment:

      Slider 0.61 jdk 1.8

    • Sprint:
      Slider April #1

      Description

      slider registry --getconf hbase-site --name hb1

      2015-05-16 11:16:37,829 [main] INFO  impl.TimelineClientImpl - Timeline service address: http://d64:8188/ws/v1/timeline/
      2015-05-16 11:16:38,472 [main] INFO  client.RMProxy - Connecting to ResourceManager at d64/160.164.0.7:18040
      Exception: java.lang.IllegalStateException: connect in progress
      2015-05-16 11:16:38,958 [main] ERROR main.ServiceLauncher - Exception: java.lang.IllegalStateException: connect in progress
      com.sun.jersey.api.client.ClientHandlerException: java.lang.IllegalStateException: connect in progress
              at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:149)
              at com.sun.jersey.api.client.Client.handle(Client.java:648)
              at com.sun.jersey.api.client.WebResource.handle(WebResource.java:670)
              at com.sun.jersey.api.client.WebResource.get(WebResource.java:191)
              at org.apache.slider.core.registry.retrieve.RegistryRetriever.getConfigurations(RegistryRetriever.java:216)
              at org.apache.slider.client.SliderClient.actionRegistryGetConfig(SliderClient.java:3117)
              at org.apache.slider.client.SliderClient.actionRegistry(SliderClient.java:2610)
              at org.apache.slider.client.SliderClient.exec(SliderClient.java:404)
              at org.apache.slider.client.SliderClient.runService(SliderClient.java:348)
              at org.apache.slider.core.main.ServiceLauncher.launchService(ServiceLauncher.java:188)
              at org.apache.slider.core.main.ServiceLauncher.launchServiceRobustly(ServiceLauncher.java:475)
              at org.apache.slider.core.main.ServiceLauncher.launchServiceAndExit(ServiceLauncher.java:403)
              at org.apache.slider.core.main.ServiceLauncher.serviceMain(ServiceLauncher.java:630)
              at org.apache.slider.Slider.main(Slider.java:49)
      Caused by: java.lang.IllegalStateException: connect in progress
              at sun.net.www.protocol.http.HttpURLConnection.setRequestMethod(HttpURLConnection.java:516)
              at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.setRequestMethodUsingWorkaroundForJREBug(URLConnectionClientHandler.java:259)
              at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:191)
              at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:147)
              ... 13 more
      2015-05-16 11:16:38,963 [main] INFO  util.ExitUtil - Exiting with status 56
      

      It is caused by the jersey.

      Some reference
      https://bugs.openjdk.java.net/browse/JDK-8029127
      http://stackoverflow.com/questions/27571645/httpurlconnection-getinputstream-to-read-page-and-then-make-post-request

        Issue Links

          Activity

          Hide
          stevel@apache.org Steve Loughran added a comment -

          This is pretty serious. I have been testing against java 8 (1.8.0_45), but not seen this; maybe I've not been using java 8 as the client in the functional test suite.

          Looking at the comments there, especially stackoverflow, it's re-use of an existing httpconnection that's the problem, or changing HTTP request headers while the connection has already started [ http://stackoverflow.com/questions/5368535/java-httpurlconnection-issues-with-illegalstateargument-already-connected]

          Looking at the code chain for the registry GET operation, we aren't doing that in our code. Our AM webapp is set to redirect to the RM proxy if it gets a direct GET request -but at the same time, it should be GETs everywhere.

          I recall we encountered something like this before using Jersey to do the REST client, where we were trying to do some security/rest work dealing with RM Redirects that were also doing some HTTPS/HTTP conversion (when we were trying to run the AM as HTTPS).

          And looking at the code, I can see a possible code path where our code UrlConnectionOperations is trying to do some setup of the new HTTP connection (setting cache and redirect policy) after the security token has been set. Which doesn't look like a codepath to trigger the error string you are seeing in setRequestMethod].

          I'll switch my IDE to using the Java 8 SDK (I bond it to java 7 to avoid accidentally using any Java 8 classes/methods); to see how the codepath looks there.

          meanwhile, I have one question: is this a secure cluster?

          Show
          stevel@apache.org Steve Loughran added a comment - This is pretty serious. I have been testing against java 8 (1.8.0_45), but not seen this; maybe I've not been using java 8 as the client in the functional test suite. Looking at the comments there, especially stackoverflow, it's re-use of an existing httpconnection that's the problem, or changing HTTP request headers while the connection has already started [ http://stackoverflow.com/questions/5368535/java-httpurlconnection-issues-with-illegalstateargument-already-connected ] Looking at the code chain for the registry GET operation, we aren't doing that in our code. Our AM webapp is set to redirect to the RM proxy if it gets a direct GET request -but at the same time, it should be GETs everywhere. I recall we encountered something like this before using Jersey to do the REST client, where we were trying to do some security/rest work dealing with RM Redirects that were also doing some HTTPS/HTTP conversion (when we were trying to run the AM as HTTPS). And looking at the code, I can see a possible code path where our code UrlConnectionOperations is trying to do some setup of the new HTTP connection (setting cache and redirect policy) after the security token has been set. Which doesn't look like a codepath to trigger the error string you are seeing in setRequestMethod] . I'll switch my IDE to using the Java 8 SDK (I bond it to java 7 to avoid accidentally using any Java 8 classes/methods); to see how the codepath looks there. meanwhile, I have one question: is this a secure cluster?
          Hide
          stevel@apache.org Steve Loughran added a comment -

          Note: that stack trace implies that Jersey was in the codepath to try an retrofit an unsupported HTTP VERB into the operation, which it does if the property "com.sun.jersey.client.property.httpUrlConnectionSetMethodWorkaround" is set (Default = false). https://blogs.oracle.com/PavelBucek/entry/jersey_server_and_client_side

          we don't set that property. odd

          Show
          stevel@apache.org Steve Loughran added a comment - Note: that stack trace implies that Jersey was in the codepath to try an retrofit an unsupported HTTP VERB into the operation, which it does if the property "com.sun.jersey.client.property.httpUrlConnectionSetMethodWorkaround" is set (Default = false). https://blogs.oracle.com/PavelBucek/entry/jersey_server_and_client_side we don't set that property. odd
          Hide
          skaterxu qiang xu added a comment - - edited

          Hello Steve:
          I ran the slider with open source yarn 2.6 without secure.
          And today I am trying to understand the work flow, and even want to fix it.
          After reading some docs, I have some questions.
          In https://mail-archives.apache.org/mod_mbox/incubator-slider-commits/201412.mbox/%3C20141211151707.4DFF3AC094D@hades.apache.org%3E
          It mentioned about the "All these services are implemented by the Jersey JAX-RS engine, operating in an embedded Jetty Web engine, with the YARN AmWebFilter class redirecting all requests not coming from the RM Proxy IP address to that RM Proxy via a 302 (redirect-as-GET)"
          But I did not find the AmWebFilter.
          Thanks Steve, I just find your email, org.apache.hadoop.yarn.server.webproxy.amfilter.AmIpFilter, how do we use AmIpFilter?
          I did not find it in slider code.
          But I found

          { // IP filtering serviceConf.set(HADOOP_HTTP_FILTER_INITIALIZERS, AM_FILTER_NAME); And then create yarn rpc will use use this configuration But I still do not know how does resource manager know application master address How to rigeter the appInformation to YARN? (StatusKeys.INFO_AM_WEB_URL, appMasterTrackingUrl + "/"); }

          I have monitored the slider application master, it mentioned about {"uris":{"slider":"http://d64:39876/ws/v1/slider/publisher/slider","exports":"http://d64:39876/ws/v1/slider/publisher/exports"}}
          And I use the http://d64:39876/ws/v1/slider/publisher/slider, the address finally redirect to the resource manager.

          How do our code configure YARN resource manager to redirect the url to application master?
          Why use chrome to query the http://d64:39876/ws/v1/slider/publisher/slider, finally back to resource manager address in the input url?
          What code and knowledge for guice or some other thing make these magic happen?

          Thanks in advance

          Show
          skaterxu qiang xu added a comment - - edited Hello Steve: I ran the slider with open source yarn 2.6 without secure. And today I am trying to understand the work flow, and even want to fix it. After reading some docs, I have some questions. In https://mail-archives.apache.org/mod_mbox/incubator-slider-commits/201412.mbox/%3C20141211151707.4DFF3AC094D@hades.apache.org%3E It mentioned about the "All these services are implemented by the Jersey JAX-RS engine, operating in an embedded Jetty Web engine, with the YARN AmWebFilter class redirecting all requests not coming from the RM Proxy IP address to that RM Proxy via a 302 (redirect-as-GET)" But I did not find the AmWebFilter. Thanks Steve, I just find your email, org.apache.hadoop.yarn.server.webproxy.amfilter.AmIpFilter, how do we use AmIpFilter? I did not find it in slider code. But I found { // IP filtering serviceConf.set(HADOOP_HTTP_FILTER_INITIALIZERS, AM_FILTER_NAME); And then create yarn rpc will use use this configuration But I still do not know how does resource manager know application master address How to rigeter the appInformation to YARN? (StatusKeys.INFO_AM_WEB_URL, appMasterTrackingUrl + "/"); } I have monitored the slider application master, it mentioned about {"uris":{"slider":"http://d64:39876/ws/v1/slider/publisher/slider","exports":"http://d64:39876/ws/v1/slider/publisher/exports"}} And I use the http://d64:39876/ws/v1/slider/publisher/slider , the address finally redirect to the resource manager. How do our code configure YARN resource manager to redirect the url to application master? Why use chrome to query the http://d64:39876/ws/v1/slider/publisher/slider , finally back to resource manager address in the input url? What code and knowledge for guice or some other thing make these magic happen? Thanks in advance
          Hide
          stevel@apache.org Steve Loughran added a comment -
          1. org.apache.hadoop.yarn.server.webproxy.amfilter.AmIpFilter is something in the Hadoop YARN source tree —assume anything with org.apache.hadoop comes from there. You can see it on github
          2. The AM brings up a web server then tells the RM what port it is listening on; this is used to build "the original URL". (We can't change this when slider is up, so have to start IPC and web before the AM is fully configured; a small hint of a race condition we deal with by having the whole setup step synchronized().
          3. The AmIpFilter that's registered redirects all requests that aren't from the proxy host to the current proxy
          4. and apparently even the proxys can redirect between themselves on an HA cluster.

          The RM never redirects the client directly to the AM. Instead it acts as a proper HTTP proxy, one that also does SNPEGO auth of caller credentials (so you can view the web UI of your slider cluster, but other users would not be able to)

          Show
          stevel@apache.org Steve Loughran added a comment - org.apache.hadoop.yarn.server.webproxy.amfilter.AmIpFilter is something in the Hadoop YARN source tree —assume anything with org.apache.hadoop comes from there. You can see it on github The AM brings up a web server then tells the RM what port it is listening on; this is used to build "the original URL". (We can't change this when slider is up, so have to start IPC and web before the AM is fully configured; a small hint of a race condition we deal with by having the whole setup step synchronized() . The AmIpFilter that's registered redirects all requests that aren't from the proxy host to the current proxy and apparently even the proxys can redirect between themselves on an HA cluster. The RM never redirects the client directly to the AM. Instead it acts as a proper HTTP proxy, one that also does SNPEGO auth of caller credentials (so you can view the web UI of your slider cluster, but other users would not be able to)
          Hide
          skaterxu qiang xu added a comment -

          Thanks Steve:
          With your comments, I have gone through yarn proxy for AM and AM redirect request to RM code.
          Now the left thing is how to solve jdk 1.8 with jersey problem.

          Regards

          Show
          skaterxu qiang xu added a comment - Thanks Steve: With your comments, I have gone through yarn proxy for AM and AM redirect request to RM code. Now the left thing is how to solve jdk 1.8 with jersey problem. Regards
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit cac169a02aa3bbaf1eaf7bb09981e00fd573c57d in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=cac169a ]

          SLIDER-878 java 8 & jersey compatibility

          Show
          jira-bot ASF subversion and git services added a comment - Commit cac169a02aa3bbaf1eaf7bb09981e00fd573c57d in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=cac169a ] SLIDER-878 java 8 & jersey compatibility
          Hide
          stevel@apache.org Steve Loughran added a comment -

          The good news: I've managed to replicate this (intermittently) in a JUnit test case on Windows + Java 8u45; Hadoop 2.6 and java lang set to 1.8 for the whole slider compile.

          The bad news: this surfaces on Jetty 1.19 too, on an insecure cluster.

          mvn test -Pjava8 -Djersey.version=1.19 -Dtest=TestStandaloneYarnRegistryAM
          
          Show
          stevel@apache.org Steve Loughran added a comment - The good news: I've managed to replicate this (intermittently) in a JUnit test case on Windows + Java 8u45; Hadoop 2.6 and java lang set to 1.8 for the whole slider compile. The bad news: this surfaces on Jetty 1.19 too, on an insecure cluster. mvn test -Pjava8 -Djersey.version=1.19 -Dtest=TestStandaloneYarnRegistryAM
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1cecc3fcb0e80de48e0ea7ba54e607421ffea3fe in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=1cecc3f ]

          SLIDER-878 use own connection factory with controlled order on connection operations

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1cecc3fcb0e80de48e0ea7ba54e607421ffea3fe in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=1cecc3f ] SLIDER-878 use own connection factory with controlled order on connection operations
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 13ec0af54944fb2327d9123a57b3d3076548a689 in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=13ec0af ]

          SLIDER-878 turn off method workaround

          Show
          jira-bot ASF subversion and git services added a comment - Commit 13ec0af54944fb2327d9123a57b3d3076548a689 in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=13ec0af ] SLIDER-878 turn off method workaround
          Hide
          stevel@apache.org Steve Loughran added a comment -

          Here is where we are now

          1. happens client side on java 8
          2. still happens with Jersey 1.19
          3. if I comment out the bit of AMWebClient which sets the jersey client property ""com.sun.jersey.client.property.httpUrlConnectionSetMethodWorkaround" then it happens on Java 7 too.
          4. the origin of that code is SLIDER-593; the logic to handle cross HTTP/HTTPS redirects.

          I'm not exactly sure where this is happening -it may be part of the redirect chain, where the first 302/307 is received, then the code tries again with the RM Proxy.

          What's annoying here is that Jersey is setting the method every time, rather than checking to see if the current method == the new method. With that, every GET would be a no-op and there'd be no need to delve further.

          I don't know where to go from here.

          1. Ripping out Jersey 1.x and going to 2.x would (a) be traumatic and (b) offers no guarantees of a fix.
          2. Subclassing java.net.HttpUrlConnection & HttpsConnection seems convoluted: surely others have seen this problem
          Show
          stevel@apache.org Steve Loughran added a comment - Here is where we are now happens client side on java 8 still happens with Jersey 1.19 if I comment out the bit of AMWebClient which sets the jersey client property ""com.sun.jersey.client.property.httpUrlConnectionSetMethodWorkaround" then it happens on Java 7 too. the origin of that code is SLIDER-593 ; the logic to handle cross HTTP/HTTPS redirects. I'm not exactly sure where this is happening -it may be part of the redirect chain, where the first 302/307 is received, then the code tries again with the RM Proxy. What's annoying here is that Jersey is setting the method every time, rather than checking to see if the current method == the new method. With that, every GET would be a no-op and there'd be no need to delve further. I don't know where to go from here. Ripping out Jersey 1.x and going to 2.x would (a) be traumatic and (b) offers no guarantees of a fix. Subclassing java.net.HttpUrlConnection & HttpsConnection seems convoluted: surely others have seen this problem
          Hide
          stevel@apache.org Steve Loughran added a comment -

          Note that the Slider IPC rest API doesn't see this, it's only the enum and GET of configurations, which has some different Jersey setup code. Which implies that difference is the problem

          Show
          stevel@apache.org Steve Loughran added a comment - Note that the Slider IPC rest API doesn't see this, it's only the enum and GET of configurations, which has some different Jersey setup code. Which implies that difference is the problem
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f1efe763eb426398669e00ff2a2b4a84651adfd2 in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=f1efe76 ]

          SLIDER-878 re-enable Jersey method workaround option in AMClient

          Show
          jira-bot ASF subversion and git services added a comment - Commit f1efe763eb426398669e00ff2a2b4a84651adfd2 in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=f1efe76 ] SLIDER-878 re-enable Jersey method workaround option in AMClient
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1cecc3fcb0e80de48e0ea7ba54e607421ffea3fe in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=1cecc3f ]

          SLIDER-878 use own connection factory with controlled order on connection operations

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1cecc3fcb0e80de48e0ea7ba54e607421ffea3fe in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=1cecc3f ] SLIDER-878 use own connection factory with controlled order on connection operations
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 13ec0af54944fb2327d9123a57b3d3076548a689 in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=13ec0af ]

          SLIDER-878 turn off method workaround

          Show
          jira-bot ASF subversion and git services added a comment - Commit 13ec0af54944fb2327d9123a57b3d3076548a689 in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=13ec0af ] SLIDER-878 turn off method workaround
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f1efe763eb426398669e00ff2a2b4a84651adfd2 in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=f1efe76 ]

          SLIDER-878 re-enable Jersey method workaround option in AMClient

          Show
          jira-bot ASF subversion and git services added a comment - Commit f1efe763eb426398669e00ff2a2b4a84651adfd2 in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=f1efe76 ] SLIDER-878 re-enable Jersey method workaround option in AMClient
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3616951225067932d62ad5642f26e395f3792450 in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=3616951 ]

          Merge branch 'feature/SLIDER-878-jersey' into develop

          1. Conflicts:
          2. pom.xml
          Show
          jira-bot ASF subversion and git services added a comment - Commit 3616951225067932d62ad5642f26e395f3792450 in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=3616951 ] Merge branch 'feature/ SLIDER-878 -jersey' into develop Conflicts: pom.xml
          Hide
          skaterxu qiang xu added a comment -

          Hello Steven, is above fix ok?
          Which branch is the fix in?

          Show
          skaterxu qiang xu added a comment - Hello Steven, is above fix ok? Which branch is the fix in?
          Hide
          stevel@apache.org Steve Loughran added a comment -

          It's not fixed yet: I can say I'm replicating things but don't know why it's only happening on one bit of Jersey use -so don't know how to make it go away. Those commits were me experiment with changes to see if I could do that.

          Show
          stevel@apache.org Steve Loughran added a comment - It's not fixed yet: I can say I'm replicating things but don't know why it's only happening on one bit of Jersey use -so don't know how to make it go away. Those commits were me experiment with changes to see if I could do that.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit e95d516a336ad1a09418559733cd6d8ee8f16a2e in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey-jdk8 from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=e95d516 ]

          SLIDER-878 move AMWebClient to using BaseRestClient for its REST operations. This drops the http/https logic

          Show
          jira-bot ASF subversion and git services added a comment - Commit e95d516a336ad1a09418559733cd6d8ee8f16a2e in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey-jdk8 from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=e95d516 ] SLIDER-878 move AMWebClient to using BaseRestClient for its REST operations. This drops the http/https logic
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8ceddfd7e8e2392cd121adc5dd8aab4993166e4a in incubator-slider's branch refs/heads/feature/SLIDER-878-jersey-jdk8 from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=8ceddfd ]

          SLIDER-878 complete move to BaseRestClient; add shortcut for the get operation there

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8ceddfd7e8e2392cd121adc5dd8aab4993166e4a in incubator-slider's branch refs/heads/feature/ SLIDER-878 -jersey-jdk8 from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=8ceddfd ] SLIDER-878 complete move to BaseRestClient; add shortcut for the get operation there
          Hide
          stevel@apache.org Steve Loughran added a comment -
          1. I can replicate this on my desktop too
          2. Not a jersey version problem
          3. I do think it's related to the HTTP/HTTPS logic in the registry code, which isn't in the newer Slider REST API code.

          I've a patch which switches to BaseRestClient for the registry code; it is passing the unit test which could replicate this problem on Java 8 on both OSX and windows. I'm doing a full slider-common test run before merging the branch (feature/SLIDER-878-jersey-jdk8) back in.

          Show
          stevel@apache.org Steve Loughran added a comment - I can replicate this on my desktop too Not a jersey version problem I do think it's related to the HTTP/HTTPS logic in the registry code, which isn't in the newer Slider REST API code. I've a patch which switches to BaseRestClient for the registry code; it is passing the unit test which could replicate this problem on Java 8 on both OSX and windows. I'm doing a full slider-common test run before merging the branch (feature/ SLIDER-878 -jersey-jdk8) back in.
          Hide
          billie.rinaldi Billie Rinaldi added a comment -

          Hey Steve, how did the testing go? Is this fix ready to be merged in?

          Show
          billie.rinaldi Billie Rinaldi added a comment - Hey Steve, how did the testing go? Is this fix ready to be merged in?
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit e95d516a336ad1a09418559733cd6d8ee8f16a2e in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=e95d516 ]

          SLIDER-878 move AMWebClient to using BaseRestClient for its REST operations. This drops the http/https logic

          Show
          jira-bot ASF subversion and git services added a comment - Commit e95d516a336ad1a09418559733cd6d8ee8f16a2e in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=e95d516 ] SLIDER-878 move AMWebClient to using BaseRestClient for its REST operations. This drops the http/https logic
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8ceddfd7e8e2392cd121adc5dd8aab4993166e4a in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=8ceddfd ]

          SLIDER-878 complete move to BaseRestClient; add shortcut for the get operation there

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8ceddfd7e8e2392cd121adc5dd8aab4993166e4a in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=8ceddfd ] SLIDER-878 complete move to BaseRestClient; add shortcut for the get operation there
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 92b299a6da699fa8cbaf60c5f74d7c9d42bd4ec3 in incubator-slider's branch refs/heads/develop from Steve Loughran
          [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=92b299a ]

          Merge branch 'feature/SLIDER-878-jersey-jdk8' into develop

          Show
          jira-bot ASF subversion and git services added a comment - Commit 92b299a6da699fa8cbaf60c5f74d7c9d42bd4ec3 in incubator-slider's branch refs/heads/develop from Steve Loughran [ https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;h=92b299a ] Merge branch 'feature/ SLIDER-878 -jersey-jdk8' into develop
          Hide
          stevel@apache.org Steve Loughran added a comment -

          Fixed in Slider 0.90-incubating; if we do a 0.81 release then this should be backported to ensure 0.8x works on java 8.

          Show
          stevel@apache.org Steve Loughran added a comment - Fixed in Slider 0.90-incubating; if we do a 0.81 release then this should be backported to ensure 0.8x works on java 8.

            People

            • Assignee:
              stevel@apache.org Steve Loughran
              Reporter:
              skaterxu qiang xu
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development

                  Agile