Migrate from junit4 to junit5 #692
Conversation
kaibocai
requested review from
anirudhgarg,
TsuyoshiUshio,
amamounelsayed,
shreyas-gopalakrishna and
kamperiadis
as code owners
| @@ -25,7 +25,6 @@ public InvocationRequestHandler(JavaFunctionBroker broker) { | |||
|
|
|||
| @Override | |||
| String execute(InvocationRequest request, InvocationResponse.Builder response) throws Exception { | |||
| WorkerLogManager.getSystemLogger().log(Level.INFO, "Java version - " + getJavaVersion()); | |||
There was a problem hiding this comment.
Any reason this log is removed? This was added to make it easier to get java version in kusto logs specifically for consumption apps as they use placeholders. I suggest we retain this.
There was a problem hiding this comment.
we can check the version by using log here
My concern is that put it in invocation is not a good place, when cx is having thousands rps, this can be kind of annoying and it may impact the throughput and performance when the rps is high as we need to run getJavaverion very frequently and log them to host from stdout.
So if we have a way to tell the java version, let's just save the resources as much as possible.
There was a problem hiding this comment.
Understand your concern. I feel it is better to retain it with a lower log level. This log specifically informs not only the java version but also the java path which is useful for the customer and us. Some customers had reached out asking how to get this information. The time we would save with one log is quite miniscule. Feel free to combine java version with the next log if it saves time.
There was a problem hiding this comment.
I moved the log to function load request handler as function load is far fewer than function invocation.
|
/azp run |
1 similar comment
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Issue describing the changes in this PR
Migrate from junit4 to junit5
Pull request checklist
release_notes.mdAdditional information
Additional PR information