[jira] [Updated] (OOZIE-3555) Remove unnecessary StandardCharsets.UTF_8.name() calls
[ https://issues.apache.org/jira/browse/OOZIE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3555: -- Attachment: OOZIE-3555.patch > Remove unnecessary StandardCharsets.UTF_8.name() calls > -- > > Key: OOZIE-3555 > URL: https://issues.apache.org/jira/browse/OOZIE-3555 > Project: Oozie > Issue Type: Improvement > Components: core >Affects Versions: 5.1.0, 5.2.0 >Reporter: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3555.patch > > > Remove unnecessary StandardCharsets.UTF_8.name() calls - where Charset could > be accepted as well instead of a String -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OOZIE-3555) Remove unnecessary StandardCharsets.UTF_8.name() calls
[ https://issues.apache.org/jira/browse/OOZIE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3555: -- Affects Version/s: 5.2.0 > Remove unnecessary StandardCharsets.UTF_8.name() calls > -- > > Key: OOZIE-3555 > URL: https://issues.apache.org/jira/browse/OOZIE-3555 > Project: Oozie > Issue Type: Improvement > Components: core >Affects Versions: 5.1.0, 5.2.0 >Reporter: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3555.patch > > > Remove unnecessary StandardCharsets.UTF_8.name() calls - where Charset could > be accepted as well instead of a String -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OOZIE-3555) Remove unnecessary StandardCharsets.UTF_8.name() calls
Zsombor Gegesy created OOZIE-3555: - Summary: Remove unnecessary StandardCharsets.UTF_8.name() calls Key: OOZIE-3555 URL: https://issues.apache.org/jira/browse/OOZIE-3555 Project: Oozie Issue Type: Improvement Components: core Affects Versions: 5.1.0 Reporter: Zsombor Gegesy Remove unnecessary StandardCharsets.UTF_8.name() calls - where Charset could be accepted as well instead of a String -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951071#comment-16951071 ] Zsombor Gegesy commented on OOZIE-3542: --- Sorry, I forgot this ticket. I've added a new patch, but due to limitation in mocking - we can't mock a final class, in this case enum - I had to write a hand-made fake enum for the tests. Unfortunately, I don't understand, what's the problem with the PreCommit build > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch, OOZIE-3542-amend-01.patch, OOZIE-3542-amend-02.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: OOZIE-3542-amend-02.patch > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch, OOZIE-3542-amend-01.patch, OOZIE-3542-amend-02.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936957#comment-16936957 ] Zsombor Gegesy commented on OOZIE-3542: --- Yes, the problem was, that the there are multiple reflective calls to the remote HDFS service, where the same error could happen - and unfortunately only one call is handled previously. The new patch adds the same checks to all calls. > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch, OOZIE-3542-amend-01.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: OOZIE-3542-amend-01.patch > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch, OOZIE-3542-amend-01.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy reopened OOZIE-3542: --- > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927884#comment-16927884 ] Zsombor Gegesy commented on OOZIE-3542: --- Sorry, I wasn't near to a laptop. I've renamed the test class in patch #4, but the SystemErasureCodingPolicies unfortunately called from ECPolicyDisabler with reflection - so it's not obvious that you couldn't change it. When Oozie could depend on Hadoop 3 directly, the mocking could be much simpler > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: OOZIE-3542-4.patch > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3542-2.patch, OOZIE-3542-3.patch, > OOZIE-3542-4.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: (was: OOZIE-3542.patch) > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3542-2.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: OOZIE-3542-2.patch > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3542-2.patch, OOZIE-3542.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
[ https://issues.apache.org/jira/browse/OOZIE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3542: -- Attachment: OOZIE-3542.patch > Handle better old Hdfs implementations in ECPolicyDisabler > -- > > Key: OOZIE-3542 > URL: https://issues.apache.org/jira/browse/OOZIE-3542 > Project: Oozie > Issue Type: Bug > Components: tools >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Attachments: OOZIE-3542.patch > > > Currently, ECPolicyDisabler checks if the local hdfs implementation has the > necessary methods to get and set erasure coding policy. However, if the > namenode implementation is old, it could throw a > org.apache.hadoop.ipc.RemoteException with > RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. > In this case, ECPolicyDisabler fails, and prevents the installation to > succeed. > This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (OOZIE-3542) Handle better old Hdfs implementations in ECPolicyDisabler
Zsombor Gegesy created OOZIE-3542: - Summary: Handle better old Hdfs implementations in ECPolicyDisabler Key: OOZIE-3542 URL: https://issues.apache.org/jira/browse/OOZIE-3542 Project: Oozie Issue Type: Bug Components: tools Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Currently, ECPolicyDisabler checks if the local hdfs implementation has the necessary methods to get and set erasure coding policy. However, if the namenode implementation is old, it could throw a org.apache.hadoop.ipc.RemoteException with RpcErrorCodeProto.ERROR_NO_SUCH_METHOD value in it. In this case, ECPolicyDisabler fails, and prevents the installation to succeed. This case should be handled just like, when erasure coding is not supported. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OOZIE-3540) Use StringBuilder instead of StringBuffer if concurrent access is not required
[ https://issues.apache.org/jira/browse/OOZIE-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920505#comment-16920505 ] Zsombor Gegesy commented on OOZIE-3540: --- Sorry, I can't figure out, what's the 'new' bug, how can I find it in the generated artifacts? > Use StringBuilder instead of StringBuffer if concurrent access is not required > -- > > Key: OOZIE-3540 > URL: https://issues.apache.org/jira/browse/OOZIE-3540 > Project: Oozie > Issue Type: Improvement > Components: core >Affects Versions: trunk >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Minor > Fix For: 5.2.0 > > Attachments: OOZIE-3540.patch > > > StringBuffer is an old relic from the distant past, Oozie shouldnt' need to > use it, unless concurrent access is expected. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3540) Use StringBuilder instead of StringBuffer if concurrent access is not required
[ https://issues.apache.org/jira/browse/OOZIE-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3540: -- Attachment: OOZIE-3540.patch > Use StringBuilder instead of StringBuffer if concurrent access is not required > -- > > Key: OOZIE-3540 > URL: https://issues.apache.org/jira/browse/OOZIE-3540 > Project: Oozie > Issue Type: Improvement > Components: core >Affects Versions: trunk >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Minor > Fix For: 5.2.0 > > Attachments: OOZIE-3540.patch > > > StringBuffer is an old relic from the distant past, Oozie shouldnt' need to > use it, unless concurrent access is expected. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (OOZIE-3540) Use StringBuilder instead of StringBuffer if concurrent access is not required
Zsombor Gegesy created OOZIE-3540: - Summary: Use StringBuilder instead of StringBuffer if concurrent access is not required Key: OOZIE-3540 URL: https://issues.apache.org/jira/browse/OOZIE-3540 Project: Oozie Issue Type: Improvement Components: core Affects Versions: trunk Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 5.2.0 StringBuffer is an old relic from the distant past, Oozie shouldnt' need to use it, unless concurrent access is expected. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3539: -- Attachment: (was: OOZIE-3539-3.patch) > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539-4.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3539: -- Attachment: OOZIE-3539-4.patch > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539-3.patch, OOZIE-3539-4.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3539: -- Attachment: OOZIE-3539-3.patch > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539-3.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3539: -- Attachment: (was: OOZIE-3539.patch) > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539-3.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917600#comment-16917600 ] Zsombor Gegesy commented on OOZIE-3539: --- Review request: https://reviews.apache.org/r/71386/ > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3539) Support http proxy/basic authentication in the command line client
[ https://issues.apache.org/jira/browse/OOZIE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3539: -- Attachment: OOZIE-3539.patch > Support http proxy/basic authentication in the command line client > -- > > Key: OOZIE-3539 > URL: https://issues.apache.org/jira/browse/OOZIE-3539 > Project: Oozie > Issue Type: Improvement > Components: client >Affects Versions: 5.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 5.2.0 > > Attachments: OOZIE-3539.patch > > > If Oozie server sits behind a proxy server, which does the kerberization > during the request forwarding, but needs basic authentication, it could only > work in an awkward way - setting header parameters manually, and configuring > the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (OOZIE-3539) Support http proxy/basic authentication in the command line client
Zsombor Gegesy created OOZIE-3539: - Summary: Support http proxy/basic authentication in the command line client Key: OOZIE-3539 URL: https://issues.apache.org/jira/browse/OOZIE-3539 Project: Oozie Issue Type: Improvement Components: client Affects Versions: 5.2.0 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 5.2.0 If Oozie server sits behind a proxy server, which does the kerberization during the request forwarding, but needs basic authentication, it could only work in an awkward way - setting header parameters manually, and configuring the proxy to allow unauthenticated OPTION request. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3488: -- Attachment: OOZIE-3488-3.patch > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488-2.patch, OOZIE-3488-3.patch, OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3488: -- Attachment: OOZIE-3488-2.patch > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488-2.patch, OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840380#comment-16840380 ] Zsombor Gegesy commented on OOZIE-3488: --- Thanks, really good suggestions, I wasn't aware of this two little JDK helper method/class, I will open a new ticket about them, when I have time. > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839554#comment-16839554 ] Zsombor Gegesy commented on OOZIE-3488: --- Thanks. I've checked, and first I tried to focus on the methods, where there are clear, JVM based alternatives exist. ImmutableList/ImmutableMap/ImmutableSet could be converted too, but they are used somewhere more as sign of contract - like in org.apache.oozie.fluentjob.api.workflow.Parameters. Preconditions and Joiner can be substituted with commons-lang3, or some other commons-lib if agreed. There are still 253 'import com.google.common' in the code base, so it will become huge, if we try to merge it once, so I think, better postpone the rest for other tickets. > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3488: -- Attachment: OOZIE-3488.patch > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3488: -- Attachment: (was: OOZIE-3488.patch) > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OOZIE-3488) Migrate from guava classes to the base Java implementations
[ https://issues.apache.org/jira/browse/OOZIE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated OOZIE-3488: -- Attachment: OOZIE-3488.patch > Migrate from guava classes to the base Java implementations > --- > > Key: OOZIE-3488 > URL: https://issues.apache.org/jira/browse/OOZIE-3488 > Project: Oozie > Issue Type: Improvement >Reporter: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 5.2.0 > > Attachments: OOZIE-3488.patch > > > In Oozie, guava classes are used even when Java 8 already provides a > compatible implementation, removing these usages would reduce the dependency > to guava (which is regularly a headache due to her backward incompatible > changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OOZIE-3488) Migrate from guava classes to the base Java implementations
Zsombor Gegesy created OOZIE-3488: - Summary: Migrate from guava classes to the base Java implementations Key: OOZIE-3488 URL: https://issues.apache.org/jira/browse/OOZIE-3488 Project: Oozie Issue Type: Improvement Reporter: Zsombor Gegesy Fix For: 5.2.0 In Oozie, guava classes are used even when Java 8 already provides a compatible implementation, removing these usages would reduce the dependency to guava (which is regularly a headache due to her backward incompatible changes) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3328) Create Hive compatibility action executor to run hive actions using beeline
[ https://issues.apache.org/jira/browse/OOZIE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809911#comment-16809911 ] Zsombor Gegesy commented on OOZIE-3328: --- The problem is that there are users with hundreds of workflows which use 'hive' action. But, with Hive 3, the HiveCLI is not supported anymore - so if Oozie still want to run as-is - without forcing every user to rewrite their workflow, it needs a translation layer, which accepts the same parameters and flags as the original hive action, but calls the Beeline tool under the hood. AFAIK, the big difference between HiveCLI and Beeline is the different delegation tokens, the use of the beeline-site.xml, and the different JDBC URL handling. > Create Hive compatibility action executor to run hive actions using beeline > --- > > Key: OOZIE-3328 > URL: https://issues.apache.org/jira/browse/OOZIE-3328 > Project: Oozie > Issue Type: Task > Components: action, core >Affects Versions: 5.0.0, 4.3.1 >Reporter: Denes Bodo >Assignee: Denes Bodo >Priority: Major > Labels: features, usability > > If I am correct then Hive will not support HiveCli for long and Oozie may > have to handle this. > A new executor shall be created which can understand the original hive action > format while this executor shall run the action using beeline. > What are your thoughts? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OOZIE-3304) Parsing sharelib timestamps is not threadsafe
[
https://issues.apache.org/jira/browse/OOZIE-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563785#comment-16563785
]
Zsombor Gegesy commented on OOZIE-3304:
---
It seems to be a network issue in the tests:
{code}
java.util.concurrent.ExecutionException: java.net.ConnectException: Call From
asf917.gq1.ygridcore.net/67.195.81.137 to localhost:40116 failed on connection
exception: java.net.ConnectException: Connection refused; For more details see:
http://wiki.apache.org/hadoop/ConnectionRefused
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.oozie.tools.TestCopyTaskCallable.performAndCheckCallCopyTask(TestCopyTaskCallable.java:130)
at
org.apache.oozie.tools.TestCopyTaskCallable.testCallCopyTaskMoreFilesThanThreads(TestCopyTaskCallable.java:100)
{code}
The thread local variable initialization only happens, when it first accessed,
so just creating hundreds of threads, shouldn't create hundreds of new
SimpleDateFormat, and shouldn't trigger timeouts.
> Parsing sharelib timestamps is not threadsafe
> -
>
> Key: OOZIE-3304
> URL: https://issues.apache.org/jira/browse/OOZIE-3304
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.0.0b1, 4.3.1
>Reporter: Denes Bodo
>Assignee: Denes Bodo
>Priority: Critical
> Labels: usability
> Attachments: OOZIE-3304-001.patch, OOZIE-3304-002.patch
>
>
> In rare cases the following Exception can be read in log files when an action
> fails:
> {code:java}
> org.apache.oozie.action.ActionExecutorException: NumberFormatException:
> multiple points
> at
> org.apache.oozie.action.ActionExecutor.convertException(ActionExecutor.java:446)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.submitLauncher(JavaActionExecutor.java:1271)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.start(JavaActionExecutor.java:1472)
> at
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:234)
> at
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:65)
> at org.apache.oozie.command.XCommand.call(XCommand.java:287)
> at
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:332)
> at
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:261)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NumberFormatException: multiple points
> at
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1890)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at java.text.DigitList.getDouble(DigitList.java:169)
> at java.text.DecimalFormat.parse(DecimalFormat.java:2056)
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2160)
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
> at java.text.DateFormat.parse(DateFormat.java:364)
> at
> org.apache.oozie.service.ShareLibService.getLatestLibPath(ShareLibService.java:727)
> at
> org.apache.oozie.service.ShareLibService.getShareLibRootPath(ShareLibService.java:595)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.getSharelibRoot(JavaActionExecutor.java:1297)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.initShareLibExcluder(JavaActionExecutor.java:858)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.setLibFilesArchives(JavaActionExecutor.java:866)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.submitLauncher(JavaActionExecutor.java:1156)
> ... 11 more
> {code}
> or
> {code:java}
> 2018-07-12 04:48:52,649 WARN ForkedActionStartXCommand:523 -
> SERVER[ctr-e138-1518143905142-410551-01-03.hwx.site] USER[user] GROUP[-]
> TOKEN[] APP[demo-wf] JOB[023-180712043119670-oozie-oozi-W]
> ACTION[023-180712043119670-oozie-oozi-W@streaming-node] Error starting
> action [streaming-node]. ErrorType [ERROR], ErrorCode
> [NumberFormatException], Message [NumberFormatException: For input string: ""]
> org.apache.oozie.action.ActionExecutorException: NumberFormatException: For
> input string: ""
> at
>
[jira] [Commented] (OOZIE-3304) Parsing sharelib timestamps is not threadsafe
[
https://issues.apache.org/jira/browse/OOZIE-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547520#comment-16547520
]
Zsombor Gegesy commented on OOZIE-3304:
---
Creating new SimpleDateFormat object is perfectly fine, unless you want to
create millions of objects in seconds. However, there are already replacements
for SimpleDateFormat developed, for example in commons-lang the
[FastDateFormat|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/FastDateFormat.html]
or in JDK 8 the
[DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html]
> Parsing sharelib timestamps is not threadsafe
> -
>
> Key: OOZIE-3304
> URL: https://issues.apache.org/jira/browse/OOZIE-3304
> Project: Oozie
> Issue Type: Bug
> Components: core
>Affects Versions: 5.0.0b1, 4.3.1
>Reporter: Denes Bodo
>Assignee: Denes Bodo
>Priority: Critical
> Labels: usability
>
> In rare cases the following Exception can be read in log files when an action
> fails:
> {code:java}
> org.apache.oozie.action.ActionExecutorException: NumberFormatException:
> multiple points
> at
> org.apache.oozie.action.ActionExecutor.convertException(ActionExecutor.java:446)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.submitLauncher(JavaActionExecutor.java:1271)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.start(JavaActionExecutor.java:1472)
> at
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:234)
> at
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:65)
> at org.apache.oozie.command.XCommand.call(XCommand.java:287)
> at
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:332)
> at
> org.apache.oozie.service.CallableQueueService$CompositeCallable.call(CallableQueueService.java:261)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.oozie.service.CallableQueueService$CallableWrapper.run(CallableQueueService.java:179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NumberFormatException: multiple points
> at
> sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1890)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at java.text.DigitList.getDouble(DigitList.java:169)
> at java.text.DecimalFormat.parse(DecimalFormat.java:2056)
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2160)
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
> at java.text.DateFormat.parse(DateFormat.java:364)
> at
> org.apache.oozie.service.ShareLibService.getLatestLibPath(ShareLibService.java:727)
> at
> org.apache.oozie.service.ShareLibService.getShareLibRootPath(ShareLibService.java:595)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.getSharelibRoot(JavaActionExecutor.java:1297)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.initShareLibExcluder(JavaActionExecutor.java:858)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.setLibFilesArchives(JavaActionExecutor.java:866)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.submitLauncher(JavaActionExecutor.java:1156)
> ... 11 more
> {code}
> or
> {code:java}
> 2018-07-12 04:48:52,649 WARN ForkedActionStartXCommand:523 -
> SERVER[ctr-e138-1518143905142-410551-01-03.hwx.site] USER[user] GROUP[-]
> TOKEN[] APP[demo-wf] JOB[023-180712043119670-oozie-oozi-W]
> ACTION[023-180712043119670-oozie-oozi-W@streaming-node] Error starting
> action [streaming-node]. ErrorType [ERROR], ErrorCode
> [NumberFormatException], Message [NumberFormatException: For input string: ""]
> org.apache.oozie.action.ActionExecutorException: NumberFormatException: For
> input string: ""
> at
> org.apache.oozie.action.ActionExecutor.convertException(ActionExecutor.java:446)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.submitLauncher(JavaActionExecutor.java:1271)
> at
> org.apache.oozie.action.hadoop.JavaActionExecutor.start(JavaActionExecutor.java:1472)
> at
> org.apache.oozie.command.wf.ActionStartXCommand.execute(ActionStartXCommand.java:234)
> at
> org.apache.oozie.command.wf.ForkedActionStartXCommand.execute(ForkedActionStartXCommand.java:41)
> at
>
