Return-Path: X-Original-To: apmail-hama-user-archive@www.apache.org Delivered-To: apmail-hama-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6DA1B10A89 for ; Mon, 7 Oct 2013 10:15:34 +0000 (UTC) Received: (qmail 90696 invoked by uid 500); 7 Oct 2013 10:15:33 -0000 Delivered-To: apmail-hama-user-archive@hama.apache.org Received: (qmail 90488 invoked by uid 500); 7 Oct 2013 10:15:27 -0000 Mailing-List: contact user-help@hama.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hama.apache.org Delivered-To: mailing list user@hama.apache.org Received: (qmail 90472 invoked by uid 99); 7 Oct 2013 10:15:25 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Oct 2013 10:15:25 +0000 Received: from localhost (HELO mail-vb0-f50.google.com) (127.0.0.1) (smtp-auth username millecker, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Oct 2013 10:15:24 +0000 Received: by mail-vb0-f50.google.com with SMTP id x14so3285563vbb.23 for ; Mon, 07 Oct 2013 03:15:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=e4hGgdIf8Mnlpf9NXP0Wf9qjsbRuJKuHih3qaE89Jfc=; b=BADxQ/85f7gZM9HYJeTKiSCTw9El1oK/rQAs2De8C7ZUSz//WoXdBgPaX5558ut28J uI+6YH+si/ix2uGs1hSe5wACT9faeYpsEJySfnvClegWOloZyAIN46Nv8o7cKiXTJ4yi sSRmwHolZsDoUWbr7qdSp0EnjGBezm2KZySI02eSNDYaTsqXJc0iZPQopg8F5wfDC0Ci /vKFl88oiBQBydFNGtRNmcC9YhOs+C5w2nPKy4cCrjW5+cuUbjfbtLKKetLLq86jd04y t6rqGoIuA2DTuIEbzddtdFfyiCAUiVtYP0us12pq7TFDjqEP4YkSGVZFmapeugTt7EKE p/8w== X-Gm-Message-State: ALoCoQneJhYcYmsdQRtbEAoQSIp+Q/xjjALTjVIsAlNxprit3HFxE+4Vs7Um1UU9pCv+kUqMikzv MIME-Version: 1.0 X-Received: by 10.52.227.6 with SMTP id rw6mr4348643vdc.19.1381140923034; Mon, 07 Oct 2013 03:15:23 -0700 (PDT) Received: by 10.220.46.73 with HTTP; Mon, 7 Oct 2013 03:15:22 -0700 (PDT) X-Originating-IP: [138.232.227.139] In-Reply-To: References: Date: Mon, 7 Oct 2013 12:15:22 +0200 Message-ID: Subject: Re: readNext semantic and failure after cleanup From: Martin Illecker To: user@hama.apache.org, shapovalov@graphics.cs.msu.su Content-Type: multipart/alternative; boundary=089e011616601a439104e823ee5b --089e011616601a439104e823ee5b Content-Type: text/plain; charset=ISO-8859-1 Hi Roman, sorry for the delay. So, the text protocol does not support it, or does it lack only in the > Python wrapper? Yes only the Python wrapper does not support it. The Hama Pipes protocol (C++) does support custom partitioning. I could reproduce the exception, which is occurring during the protocol shutdown only in Streaming API. 13/09/30 16:32:09 ERROR protocol.UplinkReader: > java.lang.NullPointerException > at org.apache.hama.pipes.protocol.UplinkReader.run( > UplinkReader.java:127) It was a problem in the Python wrapper and I fixed it [1] in my github repository [2]. If I send any message of the length L, I receive the message with > additional (L-1)/2 '^@' symbols after it. > So, I use the following workaround. In the BSPPeer.getCurrentMessage(): > return line[:len(line)-len(line)//3] > instead of > return line I could not locate the cause [3] for your currentMessage length problem, so I committed your workaround [4]. Then it seems the easiest way to work it > around is to have the master thread resend those records to slaves... > if they are not very big. > Yes this would be an option but partitioning should be preferred. Any chance to switch to Hama Pipes C++? Martin [1] https://github.com/millecker/HamaStreaming/commit/95466287e883a892f85427303ff255bc52b00b9a [2] https://github.com/millecker/HamaStreaming [3] https://github.com/apache/hama/blob/trunk/core/src/main/java/org/apache/hama/pipes/protocol/StreamingProtocol.java#L94 [4] https://github.com/millecker/HamaStreaming/commit/12ceb0d2db5d088004566592e42431ee40558fa7 2013/10/1 Roman Shapovalov > It seems that the file is lost in communication. Here is a copy: > > https://dl.dropboxusercontent.com/u/42489708/MasterSlaveBSP.py > > Roman > > > On Tue, Oct 1, 2013 at 6:13 PM, Roman Shapovalov > wrote: > > Hi Martin, > > > >> it seems you have forgotten the attachment. > > > > I can see one in the message I sent. Attaching again, try this. > > > > > >> But currently the Hama Streaming API [2] does not support partitioning. > > > > So, the text protocol does not support it, or does it lack only in the > > Python wrapper? > > > > So, the default partitioning is arbitrary, regardless of who is > > reading and who is not? Then it seems the easiest way to work it > > around is to have the master thread resend those records to slaves... > > if they are not very big. > > > > Thanks, > > Roman > > > > On Tue, Oct 1, 2013 at 9:30 AM, Martin Illecker > wrote: > >> Hi Roman, > >> > >> it seems you have forgotten the attachment. (your code) > >> > >> ad 1) > >> I would solve this by using a custom partitioner. > >> A custom partitioner defines which records are distributed to which > tasks. > >> > >> Here is some C++ partitioner example [1]. > >> e.g., key 3,6,9 partitioner should return 1 > >> and key 2,5,8 should return 2 > >> > >> But currently the Hama Streaming API [2] does not support partitioning. > >> Only Hama Pipes C++ supports it. > >> > >> ad 2) > >> Please submit your code, I will have a look at this exception. > >> Or please submit the tasklog. > >> > >> Martin > >> > >> [1] > >> > https://github.com/apache/hama/blob/trunk/c%2B%2B/src/main/native/examples/impl/matrixmultiplication.cc#L131-138 > >> [2] > >> > https://github.com/millecker/HamaStreaming/blob/1009bb1a6472d11f5dd3af9dc07fe64547dd0290/BinaryProtocol.py#L37-38 > >> > >> 2013/9/30 Roman Shapovalov > >> > >>> Hello all, > >>> > >>> I am developing a toy master-slave application for the Python > >>> streaming interface. There are two issues. > >>> > >>> 1. What is the semantics of the readNext command? > >>> > >>> If I run 3 tasks -- one of them is master who does not read input, -- > >>> slaves take turn to read records, but each of them reads only each > >>> third example, e.g. slave#1 reads records 3,6,9, while slave#2 reads > >>> 2,5,8. So 1/3 of records are skipped, as if the master task would read > >>> them. > >>> > >>> So, what is the exact semantics? Is there any best practice to make > >>> each example read by some task (but not the master). > >>> > >>> > >>> 2. After the code is executed (and the output is written), the job > >>> fails. All the task logs contain the following text: > >>> > >>> 13/09/30 16:32:09 ERROR protocol.UplinkReader: > >>> java.lang.NullPointerException > >>> at > >>> org.apache.hama.pipes.protocol.UplinkReader.run(UplinkReader.java:127) > >>> > >>> The exception is raised even if I don't use pipes at all. Since it > >>> shows up after cleanup, it is not critical for the program, but it may > >>> indicate some misuse by me or bugs in the Hama code. > >>> > >>> Please look at that issue. My code is attached. > >>> > >>> Roman > >>> > --089e011616601a439104e823ee5b--