I am in favor of splitting our UI from our http APIs. Our inheritance from Hadoop has served to expedite, but also complicated this aspect. Having the web dependencies in mapreduce has also caused classpath conflicts over the years. It also might be interesting to have separate thread pools for UI handlers vs. API handlers.
A while back I introduced a new pattern of using a (relatively) modern jersey for webservice endpoints. I don't know if adopting that further would help in this effort. As I recall, it achieved some of the modularity that you describe, though it all resides its own package in the same hbase-server jar. On Fri, Oct 25, 2024 at 8:38 AM Istvan Toth <st...@apache.org> wrote: > > Currently the Master and RegionServer modules include both the RPC server > functionality and the WebUI (ant JMX and metrics) HTTP server code. > > My problem with this is that we do include these in hbase-server.jar, and > as such they are also inherited by the hbase mapreduce classpath, which is > bloat and has possible CVE implications. > (Or at the very least we include code that we don't have half the > libraries for on the classpath) > > What is your opinion on splitting out the HTTP functionality into separate > module(s), and separate JAR(s) from hbase-server ? > > It's a bit tricky, since we start the RPC and HTTP servers together, so > we'd either have to move the main and startup classes to the HTTP module, > or separate the startup code. > > Another way to look at this is to separate the code needed by integrations > and the code needed for actually running network services, in which case > even the actual RPC server initialization could be split out. > > Is this even possible, or do I miss dependencies ? > If possible, is this something you see value in ? > I don't have the bandwidth to work on this short term but Nihal's recent > work has got me thinking about this topic. > (I'm thinking strictly about hbase-server, not the REST of Thrift servers, > where http is integral) > > Istvan
