[
https://issues.apache.org/jira/browse/HDDS-2067?focusedWorklogId=318907&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-318907
]
ASF GitHub Bot logged work on HDDS-2067:
----------------------------------------
Author: ASF GitHub Bot
Created on: 26/Sep/19 10:24
Start Date: 26/Sep/19 10:24
Worklog Time Spent: 10m
Work Description: elek commented on pull request #1501: HDDS-2067. Create
generic service facade with tracing/metrics/logging support
URL: https://github.com/apache/hadoop/pull/1501#discussion_r328546227
##########
File path:
hadoop-hdds/framework/src/main/java/org/apache/hadoop/hdds/server/OzoneProtocolMessageDispatcher.java
##########
@@ -0,0 +1,88 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.hadoop.hdds.server;
+
+import org.apache.hadoop.hdds.function.FunctionWithServiceException;
+import org.apache.hadoop.hdds.tracing.TracingUtil;
+import org.apache.hadoop.ozone.protocolPB.ProtocolMessageMetrics;
+
+import com.google.protobuf.ProtocolMessageEnum;
+import com.google.protobuf.ServiceException;
+import io.opentracing.Scope;
+import org.slf4j.Logger;
+
+/**
+ * Dispatch message after tracing and message logging for insight.
+ * <p>
+ * This is a generic utility to dispatch message in ServerSide translators.
+ * <p>
+ * It logs the message type/content on DEBUG/TRACING log for insight and create
+ * a new span based on the tracing information.
+ */
+public class OzoneProtocolMessageDispatcher<REQUEST, RESPONSE> {
+
+ private String serviceName;
+
+ private final ProtocolMessageMetrics protocolMessageMetrics;
+
+ private Logger logger;
+
+ public OzoneProtocolMessageDispatcher(String serviceName,
+ ProtocolMessageMetrics protocolMessageMetrics, Logger logger) {
+ this.serviceName = serviceName;
+ this.protocolMessageMetrics = protocolMessageMetrics;
+ this.logger = logger;
+ }
+
+ public RESPONSE processRequest(
+ REQUEST request,
+ FunctionWithServiceException<REQUEST, RESPONSE> methodCall,
+ ProtocolMessageEnum type,
+ String traceId) throws ServiceException {
+ Scope scope = TracingUtil
Review comment:
There is a scope.close in the final branch.
This is the limitation of the auto-closable try catch block: with that
approach the scope can't be used in the catch.
scope supports to mark the current scope as failed (which is not yet added
to the code) which requires to follow this approach.
See [this](https://github.com/opentracing/opentracing-java) link:
> ScopeManager.active(Span, boolean) and SpanBuilder.startActive() have been
deprecated as part of removing automatic Span finish upon Scope close, as doing
it through try-with statements would make it hard to properly handle errors
(Span objects would get finished before a catch block would be reached). This
improves API safety, and makes it more difficult to do the wrong thing and end
up with unexpected errors.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 318907)
Time Spent: 2.5h (was: 2h 20m)
> Create generic service facade with tracing/metrics/logging support
> ------------------------------------------------------------------
>
> Key: HDDS-2067
> URL: https://issues.apache.org/jira/browse/HDDS-2067
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Marton Elek
> Assignee: Marton Elek
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.5.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> We started to use a message based GRPC approach. Wen have only one method and
> the requests are routed based on a "type" field in the proto message.
> For example in OM protocol:
> {code}
> /**
> The OM service that takes care of Ozone namespace.
> */
> service OzoneManagerService {
> // A client-to-OM RPC to send client requests to OM Ratis server
> rpc submitRequest(OMRequest)
> returns(OMResponse);
> }
> {code}
> And
> {code}
> message OMRequest {
> required Type cmdType = 1; // Type of the command
> ...
> {code}
> This approach makes it possible to use the same code to process incoming
> messages in the server side.
> ScmBlockLocationProtocolServerSideTranslatorPB.send method contains the logic
> of:
> * Logging the request/response message (can be displayed with ozone insight)
> * Updated metrics
> * Handle open tracing context propagation.
> These functions are generic. For example
> OzoneManagerProtocolServerSideTranslatorPB use the same (=similar) code.
> The goal in this jira is to provide a generic utility and move the common
> code for tracing/request logging/response logging/metrics calculation to a
> common utility which can be used from all the ServerSide translators.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
