[
https://issues.apache.org/jira/browse/HBASE-24066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068122#comment-17068122
]
Josh Elser commented on HBASE-24066:
------------------------------------
{quote} it strikes me as something that makes HBase less stable in production,
not more
{quote}
It certainly has no chance of making HBase more stable, no. However, I don't
see a very big risk of a user (or collection of users) DDOS'ing the Master (as
opposed to a RegionServer) being a large risk to stability. Point taken,
nonetheless.
{quote}What's wrong with the {{bin/hbase}} script
{quote}
Users of HBase do not always exist on the cluster where HBase is running. This
is not for people who can access the cluster nodes directly because, as you
indicate, they already have a full-fledged classpath/environment set up for
them to use. I see this coming up more and more often where groups running
HBase don't _want_ users to be on the system directly for fear of doing things
on the same hardware that could impact shared services. For example, if you
want to write some application that reads/writes to HBase, we'll launch some
new hosts/containers where you are allowed to "go to town" without fear of
locking up that same node.
{quote}Why would be burden production hosts with artifact distribution? Why
would we encourage deployments where the production hosts are on the same
networks as developers? There are plenty of other means of distributing
artifacts available to an organization, means that do not couple development to
production, that are managed directly by IT and IT's policies.
{quote}
I agree with you that this isn't what we would call a "production ready"
solution in that it wouldn't effectively scale to 100's of users at a large
corporation. It started off as a "thought experiment", but I ended up really
liking how it felt as a user.
{quote}Do we not distribute these artifacts via our tarballs? Wouldn't they be
installed on any host via "normal" means?
{quote}
We have the "client" tarball which can localize a full client environment (sans
getting proper hbase configuration, but this also does nothing to solve that
problem; moving past that). This is essentially giving you that "{{bin/hbase}}
feel" from wherever you're coming from. As "HBase the project", we don't do a
good job of encouraging users to actually use this client tarball. I like the
client tarball, but how do we prescribe users to actually use that thing? I
think we've all struggled to evangelize the client tarball (we barely
acknowledge it IMO, but that's also on me having written part of it).
The idea of this change is to try to provide something which is easier for a
user to consume without dictating how they bundle/package their applications.
If they can build an application to an API and then dynamically get the
implementation of that API at runtime from the system they're about to talk to,
that sounds to me like a win. e.g. say IT notices that there's a critical HBase
bug and they upgrade HBase to patch that issue. Clients which dynamically
pulled the newest client jar would just pick up the fix. I've seen many, many
times where users will take a copy of a client jar exactly once, put it in
their application, and expect to use that jar until the day they die. This also
encourages us to take advantage of our better API stability that we've been
driving in 2.x.
To try to drive it home: I will agree with you that serving a large binary blob
out of a Java process is a smell and isn't something that will work for edge
cases. However, I do think this is improving part of our population's lives. I
appreciate you taking the time to quickly write back and I will respect your
opinion if I've not swayed it at all. I was worried that I'd not given enough
context to show what I was seeing.
> Expose shaded clients through WebUI as Maven repository
> -------------------------------------------------------
>
> Key: HBASE-24066
> URL: https://issues.apache.org/jira/browse/HBASE-24066
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Minor
>
> Props to [~busbey] for this idea.
> We have a number of shaded jars which are (largely) sufficient for launching
> any Java application against HBase. However, if users have multiple versions
> of HBase in their organization, it might be confusing to know "which client"
> do I need to use? Can we expose our shaded clients from HBase in such a way
> that build tools can just ask HBase for the client jars they should use?
> The idea here is that we can use embedded Jetty to "fake" out a Maven
> repository that users can put in their client applications. We have no extra
> burden from HBase because we already are packaging these jars. I'll link an
> example Maven application which uses this "feature".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
