[
https://issues.apache.org/jira/browse/TAJO-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234251#comment-14234251
]
ASF GitHub Bot commented on TAJO-1143:
--------------------------------------
Github user ykrips commented on the pull request:
https://github.com/apache/tajo/pull/280#issuecomment-65643665
Hello @hyunsik ,
Thank you for your appreciation.
I totally understand what a diagnosis phase have. This is my missing point,
and I will add it to this patch.
Now let's discuss about the naming issue. At first, I feel that this rule
engine and some pre-defined rules will cover overall functionalities of Tajo
cluster components. For instance, these rules will check or verify status of
connectivity, configurations, and so on. With my rule design, I gave a general
name to these classes. Otherwise, I think that it could be limiting the scope
of rule implementation.
> TajoMaster, TajoWorker, and TajoClient should have diagnosis phase at startup
> -----------------------------------------------------------------------------
>
> Key: TAJO-1143
> URL: https://issues.apache.org/jira/browse/TAJO-1143
> Project: Tajo
> Issue Type: Improvement
> Components: client, query master, tajo master
> Reporter: Hyunsik Choi
> Assignee: Jihun Kang
> Fix For: 0.9.1
>
>
> I propose that all cluster components (TajoMaster, TajoWorker, and
> TajoClient) in a Tajo cluster should have a diagnosis phase to eliminate or
> detect invalid situations prior to runtime query errors.
> For example, your query can cause some runtime exception due to wrong config
> after a query takes 2 hours. This situation is definitely not acceptable in
> production.
> I think that the diagnosis phase should check all configs, connectivities
> among cluster components, and status of workers.
> In detail, we need a diagnosis executor, extensible diagnosis rule interface,
> and its rules. Also, one of diagnosis rules would be TAJO-1114.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)