Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5D565189D8 for ; Thu, 6 Aug 2015 01:43:48 +0000 (UTC) Received: (qmail 63924 invoked by uid 500); 6 Aug 2015 01:43:47 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 63836 invoked by uid 500); 6 Aug 2015 01:43:47 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 63824 invoked by uid 99); 6 Aug 2015 01:43:47 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Aug 2015 01:43:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 08180C0470 for ; Thu, 6 Aug 2015 01:43:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.304 X-Spam-Level: ** X-Spam-Status: No, score=2.304 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id LcOc2T6ijklB for ; Thu, 6 Aug 2015 01:43:38 +0000 (UTC) Received: from oss.nttdata.co.jp (oss.nttdata.co.jp [49.212.34.109]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id 13ABF20F6D for ; Thu, 6 Aug 2015 01:43:36 +0000 (UTC) Received: from [192.168.43.164] (g1-27-253-251-6.bmobile.ne.jp [27.253.251.6]) by oss.nttdata.co.jp (Postfix) with ESMTP id 1FB7717EE02; Thu, 6 Aug 2015 10:43:25 +0900 (JST) Message-ID: <55C2BBBB.804@oss.nttdata.co.jp> Date: Thu, 06 Aug 2015 10:43:23 +0900 From: Masatake Iwasaki User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dev@hbase.apache.org, "Masatake Iwasaki [via Apache HBase]" Subject: Re: HTrace References: <53176CEF.6030806@oss.nttdata.co.jp> <53179DBB.9010006@oss.nttdata.co.jp> <53182ACE.6030404@oss.nttdata.co.jp> <1437665624124-4073471.post@n3.nabble.com> <55B6537A.4060809@oss.nttdata.co.jp> <1438015677853-4073515.post@n3.nabble.com> <55B66F97.5050605@oss.nttdata.co.jp> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.7 at oss.nttdata.co.jp X-Virus-Status: Clean Hi Priyanka, > If both client process and server use the same file to log htraces, then is > there a possibility of corruption while writing to the span log file? The client and server are running on the same host? You should use different output file for each process. It is not safe to write to the same file from multiple processes though it is not problem to write spans from multiple threads in single process. Masatake On 8/6/15 01:56, Priyanka Bhalerao-Deshpande wrote: > Hi Masatake, > > I was not able to get the client traces but I can find a workaround to > generate those spans myself and get a graph. I had one more question > related to htrace. > > If both client process and server use the same file to log htraces, then is > there a possibility of corruption while writing to the span log file? Since > there will be 2 JVMs writing to the same file. In addition, our client is > multithreaded too. I can use synchronize on the client side and make sure > multiple threads write the client spans in exclusion, however there can be > a problem if a server span is being written at the same time. Let me know > what you recommend. Thank you. > > Best Regards, > Priyanka > > On Mon, Jul 27, 2015 at 10:51 AM, Masatake Iwasaki [via Apache HBase] < > ml-node+s679495n4073518h44@n3.nabble.com> wrote: > >> > Thank you for getting back to me. Yes I see the Client_htrace.out >> getting >> > created on the client node. However it is empty. We are using >> htrace-2.04 >> > version. I believe that writes the span asynchronously. Also the >> client node >> > is running tomcat for serving requests. Would this be a problem? >> >> Hmm... Do you have multiple processes on the client? >> SpanReceiverHost must be initialized in each process. >> If you call SpanReceiverHost#getInstance in one process and >> call Trace#startSpan in another process, >> the client span is not written to file. >> >> I think running Tomcat is not related to the issue. >> >> >> > Is there any need to call closeReceivers in the client side code ? I >> tried >> > it but that did not seem to work. >> >> SpanReceiverHost#closeReceivers should be called on just before process >> exit >> but spans will be written to file immediately without that. >> >> >> >> On 7/28/15 01:47, Priyanka B wrote: >> > Hi Masatake, >> > >> > Thank you for getting back to me. Yes I see the Client_htrace.out >> getting >> > created on the client node. However it is empty. We are using >> htrace-2.04 >> > version. I believe that writes the span asynchronously. Also the >> client node >> > is running tomcat for serving requests. Would this be a problem? >> > >> > Is there any need to call closeReceivers in the client side code ? I >> tried >> > it but that did not seem to work. >> > >> > >> > Thanks, >> > Priyanka >> > >> > >> > >> > -- >> > View this message in context: >> http://apache-hbase.679495.n3.nabble.com/HTrace-tp4056705p4073515.html >> > Sent from the HBase Developer mailing list archive at Nabble.com. >> >> >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> http://apache-hbase.679495.n3.nabble.com/HTrace-tp4056705p4073518.html >> To unsubscribe from HTrace, click here >> >> . >> NAML >> >>