ntally regress things for you.
It seems like adding a way to get back the appID would be a reasonable
addition to the launcher.
- Patrick
On Tue, May 12, 2015 at 12:51 PM, Marcelo Vanzin wrote:
On Tue, May 12, 2015 at 11:34 AM, Kevin Markey
wrote:
aunches it.
I am still reading the newest code, and we are still researching options
to move forward. If there are alternatives, we'd like to know.
Kevin Markey
On 05/11/2015 01:36 AM, Mridul Muralidharan wrote:
That works when it is launched from same process - which is
unfortunate
In some applications, I have rather heavy use of Java enums which are
needed for related Java APIs that the application uses. And
unfortunately, they are also used as keys. As such, using the native
hashcodes makes any function over keys unstable and unpredictable, so we
now use Enum.name() a
for added latency.
Not sure if added latency a function of 1.0 vs 1.1 or 1.0 vs 1.1.1
changes, as we've never tested with 1.1.0. But thought I'd share the
results. (This is somewhat disappointing.)
Kevin Markey
On 11/17/2014 11:42 AM, Debasish Das wrote:
Andrew,
I put up 1.1.1 br
+1
Built -Pyarn -Phadoop-2.3 -Dhadoop.version=2.3.0
Ran current version of one of my applications on 1-node pseudocluster
(sorry, unable to test on full cluster).
yarn-cluster mode
Ran regression tests.
Thanks
Kevin
On 05/28/2014 09:55 PM, Krishna Sankar wrote:
+1
Pulled & built on MacOS X,
best,
Colin
On Thu, May 22, 2014 at 10:06 AM, Marcelo Vanzin
wrote:
Hi Kevin,
On Thu, May 22, 2014 at 9:49 AM, Kevin Markey
wrote:
The FS closed exception only effects the cleanup of the staging
directory,
not the final success or failure. I've not yet tested the effect of
changing m
ue ONLY to my user error.
The FS closed exception only effects the cleanup of the staging
directory, not the final success or failure. I've not yet tested the
effect of changing my application's initialization, use, or closing of
FileSystem.
Thanks again.
Kevin
On 05/22/2014 01
of CDH5.1.0, not 2.3 like you were
using.
best,
Colin
On Wed, May 21, 2014 at 3:34 PM, Kevin Markey wrote:
0
Abstaining because I'm not sure if my failures are due to Spark,
configuration, or other factors...
Compiled and deployed RC10 for YARN, Hadoop 2.3
per Spark 1.0.0 Yarn
d
rectory.
Also, where before Yarn would report the running program as "RUNNING",
it only reported this application as "ACCEPTED". It appeared to run two
containers when the first instance never reported that it was RUNNING.
I will post a separate note to the USER list about
ve various ASM exclusions from other
libraries, recompiling and redeploying. But I'd incur the wrath of the
rest of my team doing that, especially after a full day of tracking down
yet another (totally unrelated) library conflict.
Thanks for this maintenance release.
Kevin Markey
On 03/3
this fix.
Note that in branch 0.9, it is not fixed, neither in SBT nor in Maven.
TD
On Mon, Mar 24, 2014 at 4:38 PM, Kevin Markey wrote:
Is there any way that [SPARK-782] (Shade ASM) can be included? I see that
it is not currently backported to 0.9. But there is no single issue that
has caused
only 6 weeks away!
(For those not following 782, according to Jira comments, the SBT build
shades it, but it is the Maven build that ends up in Maven Central.)
Thanks
Kevin Markey
On 03/19/2014 06:07 PM, Tathagata Das wrote:
Hello everyone,
Since the release of Spark 0.9, we have recei
1051 is essential!
I'm not sure about the others, but anything that adds stability to
Spark/Yarn would be helpful.
Kevin Markey
On 03/20/2014 01:12 PM, Tom Graves wrote:
I'll pull [SPARK-1053] Should not require SPARK_YARN_APP_JAR when running on
YARN - JIRA and [SPARK-105
the Maven build should be
given more priority than at present. It seems a bit odd, if a Maven
project can be automatically generated from SBT, that it would take 1
year for ASM shading in Maven to catch up with SBT.
Thanks
Kevin Markey
SBT appears to have syntax for both, just like Maven. Su
14 matches
Mail list logo
