Yep, let's do this. Otherwise we will have a huge time on the mailing list
answering people why the directory is null ;)

2012/2/9 Edward J. Yoon <[email protected]>

> > We should put the fs.get(conf) into a dedicated try/catch or make the
> > message a bit better.
>
> Should we add to 0.4?
>
> On Wed, Feb 8, 2012 at 8:29 PM, Thomas Jungblut
> <[email protected]> wrote:
> > Besides that little inconsistency, we have seen a "not so precise" error
> > message.
> > Have a look here:
> > http://pastebin.com/E6RpCWEr
> >
> > From the message, the system dir was null. This is misleading because the
> > hadoop version was not 20.2.
> > You see this in the stacktrace.
> >
> > We should put the fs.get(conf) into a dedicated try/catch or make the
> > message a bit better.
> > This should save us time serving users on the mailing list having same
> > problems.
> > I also set the hadoop version in our getting started guide to 20.2,
> instead
> > of 20.x.
> >
> > 2012/2/8 Thomas Jungblut <[email protected]>
> >
> >> Wait a second please.
> >> Currently I am talking with Suraj, and he observed a problem with
> >> variables in the conf.
> >> In hama-default.xml there is "bsp.system.dir" mapped to
> >> "${hadoop.tmp.dir}/bsp/system".
> >> Where is this "hadoop.tmp.dir" configured?
> >>
> >> A bit more down the xml there is "hama.tmp.dir" defined.
> >> What do you think?
> >>
> >> 2012/2/8 Edward J. Yoon <[email protected]>
> >>
> >> If there's any objections, I'll move forward tomorrow. Let's release!
> >>>
> >>> On Mon, Feb 6, 2012 at 9:39 AM, Edward J. Yoon <[email protected]>
> >>> wrote:
> >>> > I tried many times on my clusters but it does not appear.
> >>> >
> >>> > Can you please debug it yourself? I guess, it related with
> >>> > 'RPC.stopProxy(umbilical);' or finished Task.
> >>> >
> >>> > And, let's schedule this issue to 0.5 TRUNK and release
> 0.4-incubating.
> >>> >
> >>> > Any other vote for this RC or anything else?
> >>> >
> >>> > On Mon, Feb 6, 2012 at 12:59 AM, Chia-Hung Lin <
> [email protected]>
> >>> wrote:
> >>> >> Log is at http://pastie.org/3321974
> >>> >>
> >>> >> On 5 February 2012 23:49, Chia-Hung Lin <[email protected]>
> wrote:
> >>> >>> +1 as it looks like not a showstopper.
> >>> >>>
> >>> >>> On 5 February 2012 22:43, Edward J. Yoon <[email protected]>
> >>> wrote:
> >>> >>>> I never seen that error before, but guess this is very similar
> issue
> >>> >>>> with HAMA-506.
> >>> >>>>
> >>> >>>> Will you attach your full-logs or cluster conditions here?
> >>> >>>>
> >>> >>>> And, vote if you don't want to see this log with Hama
> >>> 0.4.0-incubating.
> >>> >>>>
> >>> >>>> On Sun, Feb 5, 2012 at 8:27 PM, Chia-Hung Lin <
> [email protected]>
> >>> wrote:
> >>> >>>>> The message below is only shown in groom servers' log. The
> execution
> >>> >>>>> (e.g. hama jar example.jar pi) works without a problem.
> >>> >>>>>
> >>> >>>>> On 5 February 2012 19:26, Chia-Hung Lin <[email protected]>
> >>> wrote:
> >>> >>>>>> I get this message
> >>> >>>>>>
> >>> >>>>>> 2012-02-05 19:02:36,646 INFO org.apache.hadoop.ipc.Server: IPC
> >>> Server
> >>> >>>>>> listener on 41644: readAndProcess threw exception
> >>> java.io.IOException:
> >>> >>>>>> Connection reset by peer. Count of bytes read: 0
> >>> >>>>>> java.io.IOException: Connection reset by peer
> >>> >>>>>>        at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> >>> >>>>>>        at
> >>> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> >>> >>>>>>        at
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218)
> >>> >>>>>>        at sun.nio.ch.IOUtil.read(IOUtil.java:191)
> >>> >>>>>>        at
> >>> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
> >>> >>>>>>        at
> >>> org.apache.hadoop.ipc.Server.channelRead(Server.java:1211)
> >>> >>>>>>        at
> org.apache.hadoop.ipc.Server.access$2300(Server.java:77)
> >>> >>>>>>        at
> >>> org.apache.hadoop.ipc.Server$Connection.readAndProcess(Server.java:799)
> >>> >>>>>>        at
> >>> org.apache.hadoop.ipc.Server$Listener.doRead(Server.java:419)
> >>> >>>>>>        at
> >>> org.apache.hadoop.ipc.Server$Listener.run(Server.java:328)
> >>> >>>>>>
> >>> >>>>>> But that issue seems not relate to hama.
> >>> >>>>>>
> >>> >>>>>> On 5 February 2012 17:39, Thomas Jungblut
> >>> >>>>>> <[email protected]> wrote:
> >>> >>>>>>> Hi Edward,
> >>> >>>>>>>
> >>> >>>>>>> verified the signatures of both artifacts.
> >>> >>>>>>>
> >>> >>>>>>> Tested:
> >>> >>>>>>> - Web-UI
> >>> >>>>>>> - All examples in the 3 modes, local, pseudo distributed and
> >>> distributed
> >>> >>>>>>> (3vms)
> >>> >>>>>>>
> >>> >>>>>>> So I am +1 (binding).
> >>> >>>>>>>
> >>> >>>>>>> Great work!
> >>> >>>>>>>
> >>> >>>>>>> 2012/2/5 Edward J. Yoon <[email protected]>
> >>> >>>>>>>
> >>> >>>>>>>> Hi all,
> >>> >>>>>>>>
> >>> >>>>>>>> Here's RC3 for the Apache Hama 0.4-incubating release. This
> >>> fixes the
> >>> >>>>>>>> killed tasks' log warning issue. Thanks ChiaHung and Thomas!
> >>> >>>>>>>>
> >>> >>>>>>>> Artifacts is:
> >>> >>>>>>>> http://people.apache.org/~edwardyoon/dist/0.4-RC3/
> >>> >>>>>>>>
> >>> >>>>>>>> And, SVN Tag is:
> >>> >>>>>>>> https://svn.apache.org/repos/asf/incubator/hama/tags/0.4-RC3/
> >>> >>>>>>>>
> >>> >>>>>>>> Please test again and vote on here. :)
> >>> >>>>>>>>
> >>> >>>>>>>> This RC works for me, and I don't see any problem now.
> >>> >>>>>>>>
> >>> >>>>>>>> So, I'm +1.
> >>> >>>>>>>>
> >>> >>>>>>>> Thanks.
> >>> >>>>>>>> --
> >>> >>>>>>>> Best Regards, Edward J. Yoon
> >>> >>>>>>>> @eddieyoon
> >>> >>>>>>>>
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> --
> >>> >>>>>>> Thomas Jungblut
> >>> >>>>>>> Berlin <[email protected]>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> Best Regards, Edward J. Yoon
> >>> >>>> @eddieyoon
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Best Regards, Edward J. Yoon
> >>> > @eddieyoon
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Edward J. Yoon
> >>> @eddieyoon
> >>>
> >>
> >>
> >>
> >> --
> >> Thomas Jungblut
> >> Berlin <[email protected]>
> >>
> >
> >
> >
> > --
> > Thomas Jungblut
> > Berlin <[email protected]>
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>



-- 
Thomas Jungblut
Berlin <[email protected]>

Reply via email to