mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam B" <a...@mesosphere.io>
Subject Re: Review Request 33339: Add a Java example framework to test persistent volumes.
Date Sat, 20 Jun 2015 07:59:52 GMT


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > This is great -sorry it took so long to get to do a review.
> > 
> > Thanks for doing it, I'm quite looking forward to using it to learning more about
the Persistent Framework :)
> > it would be great if we could have a bit more comments in the code to help all other
newbies.
> > 
> > My review was fairly narrowly focused on Java style etc. - I'm expecting one of
the commiters will be able to give you feedback about using the framework.
> 
> Jie Yu wrote:
>     Sorry, this is my fault. I really don't have cycle for this at this moment. Marco,
mind sherperding this patch?
> 
> Jie Yu wrote:
>     The logic of this patch should match that in src/examples/persistent_volume_framework.cpp
> 
> Marco Massenzio wrote:
>     Jie - I would be absolutely happy to do that, with one minor hitch: I'm not a committer
:)
>     Happy to help out wherever I can, though!
> 
> haosdent huang wrote:
>     Thank you very much for your review, let me update it. @marco
> 
> haosdent huang wrote:
>     @marco Thank you for your review again. But some logic are follow the exists Java
examples and persistent_volume_framework.cpp . I am not sure change it are correct or not.
Anyway, I think I need to reflect this patch to make it more clear. After I reflect it, I
would @you and looking forward your review again. Thanks a lot.
> 
> Marco Massenzio wrote:
>     I understand that - and therein lies the problem :)
>     As you proved, code in 'examples' is widely "used as a template" (aka, copied) so
it would be great if we could set an... example, by providing great code there.
>     
>     Translating Java almost verbatim from C++ actually results in non-idiomatic constructs
that either (a) look weird to Java practitioners or (b) engender bad practices (that are then
propagated by the "oh, but that's how it's done in the other examples" - sounds familiar?
:)
>     
>     My suggestions (and I stress it here, they are "suggestions" - if committers with
more Java experience than I are happy with your code, then that's just fine) are to provide
some great examples, that improve on existing code.
>     
>     Thanks for doing this!

Thanks haosdent for coding this up, and thanks Marco for the initial review. As a Java/C++
polyglot, I'll volunteer to Shepherd this patch, if Jie will help verify that it properly
tests his feature.
Unfortunately, it seems the authors of the original Java examples/tests were not hardened
Java developers, and their poor style habits have been copied into subsequent examples. I
won't ask haosdent to solve all of those issues, or else this patch would be indefinitely
delayed. As long as it's no worse than the other examples, and adequately demonstrates/tests
the feature, I'll let it through.


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > src/examples/java/TestPersistentVolumeFramework.java, lines 529-542
> > <https://reviews.apache.org/r/33339/diff/10/?file=941652#file941652line529>
> >
> >     Please consider using Apache Commons CLI instead: https://commons.apache.org/proper/commons-cli/
> 
> haosdent huang wrote:
>     Yes, but it would add a new dependence to Maven. Is it acceptable? Other exist java
examples also simple handle the args.
> 
> Marco Massenzio wrote:
>     I am not sure what the "official policy" is here - but this is a widely used library
(and not a major dependency either) so I think we should be fine with it.
>     Anyone got any opinion on this?

Anything from Apache Commons Proper should be fine. We're all Apache here.


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > src/examples/java/TestPersistentVolumeFramework.java, lines 443-444
> > <https://reviews.apache.org/r/33339/diff/10/?file=941652#file941652line443>
> >
> >     instead of concatenating string, either use a StringBuilder or, even better:
> >     ```
> >     String.format("Received framework message from executor '%s' on slave %s: '%s'",
executorId, slaveId, data);
> >     ```
> 
> haosdent huang wrote:
>     Sure, but would not match
>     
>     ```
>     LOG(INFO) << "Received framework message from executor '" << executorId
>                   << "' on slave " << slaveId << ": '" << data
<< "'";
>     ```
>     
>     in persistent_volume_framework.cpp
> 
> Marco Massenzio wrote:
>     What do you mean? the output would be the exact same?

I agree with Marco that the output would be formatted exactly the same, and standard string
concatenation is slow in Java, so most people use StringBuilder or even String.format. On
the other hand, this test framework is not performance-critical, and none of the other Java
examples/tests use StringBuilder/String.format. Fix it as many places as you like, but I won't
hold up the patch for it.


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > src/examples/java/TestPersistentVolumeFramework.java, lines 344-352
> > <https://reviews.apache.org/r/33339/diff/10/?file=941652#file941652line344>
> >
> >     this is almost identical code to L307-315: how about factoring out to a common
`buildTaskInfo(String command)`?
> 
> haosdent huang wrote:
>     Sure, but it would not match the code 
>     
>     ```cpp
>     TaskInfo task;
>     task.set_name(shard.name);
>     task.mutable_task_id()->set_value(UUID::random().toString());
>     task.mutable_slave_id()->CopyFrom(offer.slave_id());
>     task.mutable_resources()->CopyFrom(shard.resources);
>     task.mutable_command()->set_value("test -f volume/persisted");
>     ```
>     
>     in persistent_volume_framework.cpp
> 
> Marco Massenzio wrote:
>     And, maybe, that's A Good Thing :)

More importantly, the command value doesn't match:
"test -f volume/ persisted" (yours, extra space)
"test -f volume/persisted" (original)


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > src/examples/java/TestPersistentVolumeFramework.java, line 29
> > <https://reviews.apache.org/r/33339/diff/10/?file=941652#file941652line29>
> >
> >     as this is an "example" framework, it'd be great if it could have (extensive)
javadocs: newbies and users alike are likely to look inside here first to learn (I sure did
:) and providing them with good, extensive guidance as to why stuff is done the way it is,
it would be great!
> >     
> >     Ideally, all public classes + public methods should have javadocs (not sure
if this is also in the public google java style guide, it sure was a "MUST" in our internal
one)
> >     
> >     Thanks!
> 
> haosdent huang wrote:
>     Acording to the exist java example framework (TestExecutor.java/TestMultipleExecutorsFramework.java/...),
don't have javadocs here. Do we still need add javadocs here, or keep same as other exist
examples?
> 
> Marco Massenzio wrote:
>     My preference would be to add documentation and be a "good guy" to whoever will follow
in your footstep and appreciate the comments ;)

+1 to documentation for any public classes/methods you can reasonably comment on (I know you're
not an expert yet). To decrease your documentation burden, let's pretend that the scheduler
methods you @Override have awesome documentation elsewhere, and you only need to add comments
specific to your implementation. You could also make more of these methods private, which
is generally a good idea, not just for avoiding comments. ;)


> On June 1, 2015, 4:32 p.m., Marco Massenzio wrote:
> > src/examples/java/TestPersistentVolumeFramework.java, line 239
> > <https://reviews.apache.org/r/33339/diff/10/?file=941652#file941652line239>
> >
> >     unless I'm mistaken and this is a unit test (is it?) can we please rename this
class in a more meaningful way?
> >     
> >     TestXxxx should be reserved for test classes.
> 
> haosdent huang wrote:
>     Hmm, name it to TestPersistentVolumeScheduler is follow other exist examples. Like
`TestScheduler` in `TestFramework.java`

At least a few of the other example frameworks are run as part of the unit test suite, under
ExamplesTest: https://github.com/apache/mesos/blob/0.22.1/src/tests/examples_tests.cpp#L36
See also: https://github.com/apache/mesos/blob/0.22.1/src/examples/java/test-framework.in
I'm not asking you to add TestPersistentVolumeFramework to ExamplesTests (although it would
be awesome!). I'm just explaining why some of the frameworks are named TestXxx; others are
just copycats.


- Adam


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33339/#review86113
-----------------------------------------------------------


On June 7, 2015, 1:10 a.m., haosdent huang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33339/
> -----------------------------------------------------------
> 
> (Updated June 7, 2015, 1:10 a.m.)
> 
> 
> Review request for mesos, Jie Yu and Vinod Kone.
> 
> 
> Bugs: MESOS-2610
>     https://issues.apache.org/jira/browse/MESOS-2610
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Add a Java example framework to test persistent volumes.
> 
> 
> Diffs
> -----
> 
>   configure.ac cad7f0e92eacc86d37b3f578382946db8b466531 
>   src/Makefile.am ec7f41f2114d02d3d5a1434d9799f15fe9331917 
>   src/examples/java/TestPersistentVolumeFramework.java PRE-CREATION 
>   src/examples/java/test-persistent-volume-framework.in PRE-CREATION 
>   src/tests/examples_tests.cpp f85b81562158c5499e9804d8d7b6811bb0a3ef16 
>   src/tests/java_persistent_volume_framework_test.sh PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/33339/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> haosdent huang
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message