Github user ilganeli commented on the pull request:
https://github.com/apache/spark/pull/5236#issuecomment-90726746
Andrew - if you pass the string 5000 it will be interpreted as 5000ms as
intended. I use 5s as shorthand in the code for brevity. I also believe
blockTimeoutMs is the only one that's explicitly named with units. Other ones
are not, so deprecating just that field shouldn't be difficult.
Sent with Good (www.good.com)
-----Original Message-----
From: andrewor14 [[email protected]<mailto:[email protected]>]
Sent: Tuesday, April 07, 2015 03:56 PM Eastern Standard Time
To: apache/spark
Cc: Ganelin, Ilya
Subject: Re: [spark] [SPARK-5931][CORE] Use consistent naming for time
properties (#5236)
@ilganeli<https://github.com/ilganeli> I took a quick look at this and I
believe this does not currently handle backward compatibility. For instance,
spark.storage.blockManagerSlaveTimeoutMs used to take in the string "5000", but
now I have to do "5s" otherwise it will throw an exception. The bigger issue is
that it's very strange to see a config ending with Ms to accept a value "5s" or
"20ms". I think this patch does only half of what I intended, and the other
half must accompany this half.
However, to deprecate all these configs is currently a very verbose
process. This is why I opened
SPARK-5933<https://issues.apache.org/jira/browse/SPARK-5933>, which I actually
see as a prerequisite before we solve either SPARK-5931 or SPARK-5932. For
these reasons I would suggest that we put this PR on hold for now. I definitely
do want to merge some variant of the changes here, but I don't think there's
currently a great way forward yet.
â
Reply to this email directly or view it on
GitHub<https://github.com/apache/spark/pull/5236#issuecomment-90713134>.
________________________________________________________
The information contained in this e-mail is confidential and/or proprietary
to Capital One and/or its affiliates. The information transmitted herewith is
intended only for use by the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution, copying
or other use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error, please
contact the sender and delete the material from your computer.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
