sijie commented on a change in pull request #4174: [go function] support
localrun and cluster mode for go function
URL: https://github.com/apache/pulsar/pull/4174#discussion_r279997155
##########
File path:
pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/runtime/RuntimeUtils.java
##########
@@ -89,31 +91,180 @@
if (StringUtils.isNotEmpty(extraDependenciesDir)) {
args.add("PYTHONPATH=${PYTHONPATH}:" + extraDependenciesDir);
}
+ } else if (instanceConfig.getFunctionDetails().getRuntime() ==
Function.FunctionDetails.Runtime.GO) {
+ //no-op
}
return args;
}
+ /**
+ *
+ * Different from python and java function, Go function uploads a complete
executable file(including:
+ * instance file + user code file). Its parameter list is provided to the
broker in the form of a yaml file,
+ * the advantage of this approach is that backward compatibility is
guaranteed.
Review comment:
> File.deleteOnExit deletes the file when the process that created it exits,
but the process that created this file is not the function instance process,
its the worker process. The worker process can run forever.
Correct. You need to explicitly delete the file if the instance is stopped
due to a function is stopped or deleted.
> It seems to me that you explicitly specify which arguments to parse and
the ones you don't just get ignored.
I don't think so. That's what I have tried.
```
$ go run test.go -wat
flag provided but not defined: -wat
Usage of
/var/folders/_l/j6x4h5m90l538hpmdj55l2f80000gn/T/go-build919491998/b001/exe/test:
-fork
a bool
-numb int
an int (default 42)
-svar string
a string var (default "bar")
-word string
a string (default "foo")
exit status 2
```
> I get that this would be impossible for positional arguments, but we are
not using any positional arguments. An parameters passed to the instance is in
the form of --argument_key <augument_value>
When talking about BC, it is not about what current is. It is about what the
future will be. We are not using positional arguments for now. but will it be
used in future?
> but also it is better if we can minimize these differences so that we
don't have to write a completely different code path to handle each language if
possible.
Agreed with minimizing the differences. Though I think minimizing the
differences should be done in a way that makes sense to all languages.
Currently I don't think the command-line argument approach work well for go
function in general.
Thinking about the question in a different way - Is the command-line arg
approach the best option for all languages? Does using an instance conf for
passing the function config and option work better for all languages?
At least, it was not a fun to me when debugging any instance related issues
for Java and Python. Because a) the command line is just too long; b) you have
to get all function details encoded to a string that is able to be passed in a
command line; c) the encoded function details is almost not human-readable.
Hence if Go has to use the file approach due to addressing BC concerns, for
the sake of uniformity, does it make sense (or is it better) to standardize in
the file approach. I don't expect us to do any changes in this pull request or
soon, but I DO expect people to think about what is the best approach in long
term, not just stick to what currently we have.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
