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
Add ability to list current listening TCP ports #1984
Comments
You can start as many listeners as you need. import org.h2.tools.Server;
// .....
Server s1 = Server.createTcpServer("-tcpPort", "5001", "-tcpPassword", "password1");
Server s2 = Server.createTcpServer("-tcpPort", "5002", "-tcpPassword", "password2");
s1.start();
s2.start();
// .....
s1.stop();
// .....
s1.start();
You can stop a TCP server remotely with Server.shutdownTcpServer("tcp://localhost:5002", "password2", true, false); but unfortunately you can't start it in this way, but you can create a special database and create a user-defined function in it that will launch |
@katzyn this is very helpful, thank you! I'll close this ticket after testing it out. |
@katzyn I'm able to start and stop TcpServer instances using functions, thank you! Follow-up question-- is it possible to get a list of TcpServer instances/listeners? I'm not finding not see anything in INFORMATION_SCHEMA, or a way to get a handle to the data within the TcpServer.SERVERS map. If not, would you be open to accepting a patch for this functionality? Thanks |
No, it isn't currently possible. Personally I don't think that this information should be available for everyone who has any access to any database via Perhaps we need a better infrastructure for such tasks. |
@katzyn How about a static listPorts() method on TcpServer that listed the port numbers? It wouldn't be readily available in INFORMATION_SCHEMA, and users would have to define the custom function to access remotely. The security would effectively mirror what's there to write functions to start and stop listeners. |
Unfortunately, your PR looks more like a hack and not like a proper implementation that we want to maintain. I think we need to design a new secure management infrastructure that will be able to replace the |
What would make this change less "like a hack"? |
For remote management operations, it is helpful to be able to specify a management-only port so that the "application" port can be shutdown during long running database management operations such as an upgrade or restore.
The text was updated successfully, but these errors were encountered: