hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13597) Switch KMS from Tomcat to Jetty
Date Sun, 04 Dec 2016 20:50:58 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15720576#comment-15720576
] 

Allen Wittenauer commented on HADOOP-13597:
-------------------------------------------

Oh, I see what you were concerned about. 

Looking closer at the code, I'd change the all-in-one to actually do

{code}
 hadoop_add_param HADOOP_KMS_OPTS "Dkms.config.dir=" ...
 hadoop_add_param HADOOP_KMS_OPTS "Dkms.log.dir=" ...
{code}

since that's much more likely the place where kms.config values get set. Then the whole scenario
becomes a non-issue.  There's also precedent for just doing something like:

{code}
  HADOOP_KMS_OPTS=${HADOOP_KMS_OPTS:-"-Dfoo"}
{code}

(see hdfs-config.sh)

but I'm less of a fan of that.  (We should probably undo those and use the hadoop_add_param
trick.  It's cleaner, more practical, and does a better job of actually protecting the user
from missing defaults.)

Also, be aware of the rather severe consequences that

{code}
  hadoop_deprecate_envvar KMS_CONFIG HADOOP_CONF_DIR
  hadoop_deprecate_envvar KMS_LOG HADOOP_LOG_DIR
{code}

has....  if KMS_CONFIG was never an analog to HADOOP_CONF_DIR in branch-2, I'd be tempted
to just throw a manual warning about it rather than go though deprecate.

> Switch KMS from Tomcat to Jetty
> -------------------------------
>
>                 Key: HADOOP-13597
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13597
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: kms
>    Affects Versions: 2.6.0
>            Reporter: John Zhuge
>            Assignee: John Zhuge
>         Attachments: HADOOP-13597.001.patch, HADOOP-13597.002.patch
>
>
> The Tomcat 6 we are using will reach EOL at the end of 2017. While there are other good
options, I would propose switching to {{Jetty 9}} for the following reasons:
> * Easier migration. Both Tomcat and Jetty are based on {{Servlet Containers}}, so we
don't have change client code that much. It would require more work to switch to {{JAX-RS}}.
> * Well established.
> * Good performance and scalability.
> Other alternatives:
> * Jersey + Grizzly
> * Tomcat 8
> Your opinions will be greatly appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message