[ 
https://issues.apache.org/jira/browse/HADOOP-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591204#action_12591204
 ] 

Rick Cox commented on HADOOP-3280:
----------------------------------

Allen and Owen's proposals have the significant advantage of applying to 
non-streaming tasks as well. Perhaps the prologue idea could be applied there 
--- a prologue executed before running the per-task JVM could {{setuid}}, 
{{setrusage}}, etc.

bq. Hadoop already does some environment setup (redirecting stdout and stderr) 
that I believe will be difficult to change. What I had in mind was that the 
prologue setting would be executed before the regular command. So to address 
your use cases:

PipeMapRed uses a shell post-HADOOP-2765 to set the ulimits, but doesn't need 
to assume a particular shell otherwise.

> virtual address space limits break streaming apps
> -------------------------------------------------
>
>                 Key: HADOOP-3280
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3280
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: contrib/streaming
>            Reporter: Rick Cox
>            Assignee: Amareshwari Sriramadasu
>            Priority: Blocker
>             Fix For: 0.17.0
>
>         Attachments: HADOOP-3280_0_20080418.patch
>
>
> HADOOP-2765 added a mandatory, hard virtual address space limit to streaming 
> apps based on the Java process's -Xmx setting.
> This makes it impossible to run a 64-bit streaming app that needs large 
> address spaces under a 32-bit JVM, even if one is otherwise willing to 
> dramatically increase the -Xmx setting without cause. Also, unlike Java's 
> -Xmx limit, the virtual address space limit for an arbitrary UNIX process 
> does not necessarily correspond to RAM usage, so it's likely to be a 
> relatively difficult to configure limit.
> 2765 was originally opened to allow an optional wrapper script around 
> streaming tasks, one use case for which was setting a ulimit. That approach 
> seems much less intrusive and more flexible than the final implementation. 
> The ulimit can also be trivially set by the streaming task itself without any 
> support from Hadoop.
> Marking this as an 0.17 blocker because it will break deployed apps and there 
> is no workaround available.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to