[
https://issues.apache.org/jira/browse/ZOOKEEPER-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Skye Wanderman-Milne updated ZOOKEEPER-1346:
--------------------------------------------
Attachment: ZOOKEEPER-1346.patch
This patch implements the main functionality of the new server, although there
is still work to do before this is ready to be committed.
DESIGN SUMMARY
This patch introduces a new ZK server package,
org.apache.zookeeper.server.admin. This package includes Commands.java, which
reimplements the 4lw commands from {Nio,Netty}ServerCnxn. Each new command
implements the Command interface, which includes a run method that takes a
Map<String, String> of keyword arguments. This makes it easy to run a command
with arguments specified as URL parameters. Command.run returns a Map<String,
Object>, which at minimum contains a "command" key for identifying which
command was run and a possibly-null "error" key. Commands are expected to use
the "error" entry instead of raising exceptions so as to inform users of errors
in a consistent and clear way (uncaught exceptions, i.e. programming errors,
are currently handled automatically by Jetty -- it returns a 500 status code
with the error including the stacktrace and logs the error and stacktrace).
Commands.java also has static methods for registering commands and running a
registered command given its name, which we use instead of creating and
invoking a Command instance directly. This takes care of defining available
commands and mapping names to Commands. Right now the 4lw commands are
registered in a static block in Commands.java (in the future we can allow for
pluggable commands too).
The package also includes AdminServer.java, which starts a Jetty server that
runs commands via Commands.java. Commands are run by loading a certain URL,
e.g., http://localhost:8080/command/stat. Any arguments are specified as URL
parameters, e.g., http://localhost:8080/command/set_trace_mask?traceMask=300.
The result of a Command is displayed using a CommandOutputter, which is
responsible for outputting the Map<String, Object> returned by a Command to a
PrintWriter. For now I've only included a JsonOutputter for simplicity, but I'm
also working on a TextOutputter that reproduces the output of the current 4lws.
Besides adding the new .admin package, I added a bunch of methods that
basically duplicate methods used by the current 4lws except return a Map
instead of writing to a PrintWriter. I also had to make a few changes since the
new commands are in a separate package, unlike the current 4lws.
I did not remove or change any of the current 4lw code to make this patch
easier to review. However, we may want to refactor the 4lw commands in
{Nio,Netty}ServerCnxn to use Commands.java (more below).
NEXT STEPS
Right now an AdminServer is only started in standalone mode, obviously we
should also start one for quorum peers.
TextOutputter
QUESTIONS
Should loading the embedded server be optional? If so, what's the story for the
current 4lw commands? It's very appealing to deprecate and eventually remove
them, but that would mean removing the 4lw functionality altogether for users
who opt not to include the embedded server. If we choose to keep the current
4lw commands, I'll refactor them to use the Commands class (this means we're
still stuck with all the complexity and bugs, including this one).
If loading the server is optional, what should that look like? There should
probably be a configuration parameter. It might also be nice to load the server
via reflection so users can remove Jetty from the classpath altogether.
Any thoughts on error handling?
Any thoughts on pluggable commands?
> Handle 4lws and monitoring on separate port
> -------------------------------------------
>
> Key: ZOOKEEPER-1346
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1346
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: Camille Fournier
> Assignee: Skye Wanderman-Milne
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1346_jetty.patch, ZOOKEEPER-1346.patch
>
>
> Move the 4lws to their own port, off of the client port, and support them
> properly via long-lived sessions instead of polling. Deprecate the 4lw
> support on the client port. Will enable us to enhance the functionality of
> the commands via extended command syntax, address security concerns and fix
> bugs involving the socket close being received before all of the data on the
> client end.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira