-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow dynamic update of agent parameters #45
base: master
Are you sure you want to change the base?
Conversation
70d1eb0
to
1bdcde7
Compare
@@ -27,6 +28,7 @@ | |||
|
|||
private final Profiler profiler; | |||
private final AtomicLong errorCounter = new AtomicLong(0); | |||
private ScheduledFuture<?> handler; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This "handler" field is only used by setter/getter. Kind of weird. Any reason add it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is needed to allow the the profilers to be "rescheduled" in the Agent, that is - cancel the previous registration and start a new one if profiling frequency changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not see your code invoke setHandler/getHandler. Maybe I miss something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AgentImpl#scheduleProfilers calls both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sorry I missed that previously. It is still weird that we only have setHandler/getHandler in this class. Looks like we should move the "handler" out of this class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok - refactored this even more and actually get rid of the ProfilerRunner altogether.
Made the Profiler itself Runnable.
import com.uber.profiling.util.NetworkUtils; | ||
import com.uber.profiling.util.ProcFileUtils; | ||
import com.uber.profiling.util.ProcessUtils; | ||
import com.uber.profiling.util.SparkUtils; | ||
|
||
import java.util.UUID; | ||
|
||
public class ProcessInfoBase { | ||
public abstract class ProcessInfoBase extends Profiler { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The semantic for class inheritance is establishing "is-a" relationship, see here. ProcessInfoBase should not be a Profiler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as part of this change, all classes from com.uber.profiling.profilers
are now profilers.
Agree that ProcessInfoBase extends Profiler
seems forced naming wise, but if you look for example at ProcessInfoProfiler extends ProcessInfoBase
there is a profiler eventually extending base Profiler
So my suggestion would be to ProcessInfoBase
to ProcessInfoBaseProfiler
.
Would it make sense then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the old code "ProcessInfoProfiler extends ProcessInfoBase" looks not good as well. Let me do some refactor there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the code to rename ProcessInfoBase to ProfilerBase, which makes more sense now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok - rebased on top of master
|
||
public abstract void profile(); | ||
|
||
void setRunner(ProfilerRunner runner){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding setRunner/getRunner here makes Profiler depends on ProfilerRunner, but it should not depend on it. Would suggest removing setRunner/getRunner here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. Don't like that as well :)
Thinking of it - would it make sense to actually have the ProfilerRunner
an inner class in the base Profiler
abstract class or even better make the Profiler
base class Runnable
so it can be:
- run once OR
- scheduled
depending on the Profiler type
Again, my whole idea here is to make all profilers runnable
(and hence cover both one-time and scheduled types).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I do not see your code call setRunner/getRunner though. Still prefer profiler not depending on this runner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the code change here. It is usefully to support "attaching agent". I added several comments though.
416a4df
to
5dd6680
Compare
5dd6680
to
5b9e9ce
Compare
Made the agent profilers re-entrant allowing to attach and update profiling parameters at runtime This is useful when the VM is not started with the agent but can be later attached and controlled, e.g: - update profiling interval - enabling/disabling profilers For time being only profilers parameters can be updated. Transformers, reporter not
5b9e9ce
to
d5b0ade
Compare
|
||
void setReporter(Reporter reporter); | ||
public abstract class Profiler implements Runnable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Profiler now is a Runnable
so it can be:
- either run one-off if it's not scheduled run periodically
- or, scheduled to run periodically
} | ||
} | ||
|
||
public ScheduledFuture<?> getScheduleHandler() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is needed so we can reschedule the profiler when the scheduling interval is updated at runtime
for (Profiler profiler : profilers.values()) { | ||
if (profiler.getScheduleHandler() != null) { | ||
//cancel previous task if already scheduled | ||
profiler.getScheduleHandler().cancel(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest removing getScheduleHandler() method and hide the logic of this cancelling inside the profiler. e.g.
if (profiler.isRunning()) {
profiler.cancel()
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call - updated
@boy-uber is this something you wanna integrate? Tx |
Made the agent profilers re-entrant allowing
to attach and update profiling parameters at runtime
This is useful when the VM is not started with the agent
but can be later attached and controlled, e.g:
For time being only profilers parameters can be updated.
Transformers, reporter not