Did you check task tracker log and log from your reducer to see if anythng was wrong ? Please also capture jstack output so that we can help you diagnose.
On Friday, July 9, 2010, bmdevelopment <[email protected]> wrote: > Hi, I updated to the version here: > http://github.com/kevinweil/hadoop-lzo > > However, when I use lzop for intermediate compression I > am still having trouble - the reduce phase now freezes at 99% and > eventually fails. > No immediate problem, because I can use the default codec. > But may be of concern to someone else. > > Thanks > > On Fri, Jul 9, 2010 at 1:54 PM, Ted Yu <[email protected]> wrote: >> I updated http://wiki.apache.org/hadoop/UsingLzoCompression to specifically >> mention this potential issue so that other people can avoid such problem. >> Feel free to add more onto it. >> >> On Thu, Jul 8, 2010 at 8:26 PM, bmdevelopment <[email protected]> >> wrote: >>> >>> Thanks everyone. >>> >>> Yes, using the Google Code version referenced on the wiki: >>> http://wiki.apache.org/hadoop/UsingLzoCompression >>> >>> I will try the latest version and see if that fixes the problem. >>> http://github.com/kevinweil/hadoop-lzo >>> >>> Thanks >>> >>> On Fri, Jul 9, 2010 at 3:22 AM, Todd Lipcon <[email protected]> wrote: >>> > On Thu, Jul 8, 2010 at 10:38 AM, Ted Yu <[email protected]> wrote: >>> >> >>> >> Todd fixed a bug where LZO header or block header data may fall on read >>> >> boundary: >>> >> >>> >> >>> >> http://github.com/toddlipcon/hadoop-lzo/commit/f3bc3f8d003bb8e24f254b25bca2053f731cdd58 >>> >> >>> >> >>> >> I am wondering if that is related to the issue you saw. >>> > >>> > I don't think this bug would show up in intermediate output compression, >>> > but >>> > it's certainly possible. There have been a number of bugs fixed in LZO >>> > over >>> > on github - are you using the github version or the one from Google Code >>> > which is out of date? Either mine or Kevin's repo on github should be a >>> > good >>> > version (I think we called the newest 0.3.4) >>> > -Todd >>> > >>> >> >>> >> On Wed, Jul 7, 2010 at 11:49 PM, bmdevelopment >>> >> <[email protected]> >>> >> wrote: >>> >>> >>> >>> A little more on this. >>> >>> >>> >>> So, I've narrowed down the problem to using Lzop compression >>> >>> (com.hadoop.compression.lzo.LzopCodec) >>> >>> for mapred.map.output.compression.codec. >>> >>> >>> >>> <property> >>> >>> <name>mapred.map.output.compression.codec</name> >>> >>> <value>com.hadoop.compression.lzo.LzopCodec</value> >>> >>> </property> >>> >>> >>> >>> If I do the above, I will get the Shuffle Error. >>> >>> If I use DefaultCodec for mapred.map.output.compression.codec. >>> >>> there is no problem. >>> >>> >>> >>> Is this a known issue? Or is this a bug? >>> >>> Doesn't seem like it should be the expected behavior. >>> >>> >>> >>> I would be glad to contribute any further info on this if necessary. >>> >>> Please let me know. >>> >>> >>> >>> Thanks >>> >>> >>> >>> On Wed, Jul 7, 2010 at 5:02 PM, bmdevelopment >>> >>> <[email protected]> >>> >>> wrote: >>> >>> > Hi, No problems. Thanks so much for your time. Greatly appreciated. >>> >>> > >>> >>> > I agree that it must be a configuration problem and so today I was >>> >>> > able >>> >>> > to start from scratch and did a fresh install of 0.20.2 on the 5 >>> >>> > node >>> >>> > cluster. >>> >>> > >>
