My team has recently started to use Rstudio server deployed on an Azure VM. We've recently run into an issue trying to test a plumber API. When I click the "Run API" button in Rstudio, plumber will serve the API on a randomly selected port between 3k and 10k -- unless I have specified a specific port in the global options. I've been told by our engineers that we can setup rules for port forwarding in the Windows Adaptive Firewall but they have to be specified one at a time. :cry:. I would like to be able to set the range of ports that plumber will select from so that we restrict usage to a smaller range of ports.
I think a potential solution would be modify getRandomPort
to check to see if getOption("plumber.port_range") is set before defaulting to range from 3k to 10k.
Hello fellow actuary. Yeah an option sounds good, maybe adding parameters to getRandomPort too and exposing the function. For the time being you could replicate your findPort function and feed that to the run method or the plumber port options.
There is also options(plumber.port = XYZ)
. This value can be set by you within your plumber.R
file or before you call $run()
.
@schloerke, specifying the port one at a time is a potential stop gap solution. As we bring more of our team onto rstudio server I worry about the coordinating the port usage, but a relatively small pool should be sufficient if ports aren't hardcoded into individual plumber files.
@meztez I was thinking I might start work on a PR over the weekend for this. Is there a convention on whether to have two separate options plumber.port_range.min and plumber.port_range.max vs single item, plumber.port_range that has two elements?
I don't think you need a different option, we should just maybe handle range with the current options.
options("plumber.port" = 4000:7000)
If you run plumber API from rstudio server directly, it should not matter as everything should be proxied to rstudio server port when configured correclty.
We have a similar setup to yours and we only have one outoing port allowed in the network firewall but a bunch of api can be run at the same time no problem.
Maybe I don't know about the integration issues with the Pro products but why doesn't this work?
# plumber.R
options("plumber.port" = httpuv::randomPort(min = 4000, max = 7000, n = 100))
### define the rest of your plumber router...
Or is the time difference between plumbing and running too large, which would cause issues when running concurrent apis?
Otherwise I'm up for accepting a range of port values, like 4000:7000
. But I'd rather not change it if we can help it.
Although I did make an attempt to search issues for keywords related to my feature request, I now believe I'm having the same issue as described in #569.
Also, I think many situations where a specific limited range was needed, @schloerke's suggestion using httpuv::randomPort would be a good solution. So unless the {plumber} team sees other use cases, I would suggest closing this feature request and adding a new issue to include @schloerke snippet in the "Tips & Tricks" article in the packagedown site.
Most helpful comment
Maybe I don't know about the integration issues with the Pro products but why doesn't this work?
Or is the time difference between plumbing and running too large, which would cause issues when running concurrent apis?
Otherwise I'm up for accepting a range of port values, like
4000:7000
. But I'd rather not change it if we can help it.