I went back and reread after responding, as is my custom, and I noticed the other thread about removing binary dependencies from the assembly. This was not made clear in this thread. Seems we went from thinking about removing test dependencies from the binary assembly straight to completely removing this component. I don't see a need for that escalation and may have some use for this component in the future, as mentioned below. Perhaps we can keep to the original scope?
I do not have any objections to removing test-only dependencies from our binary convenience artifacts. Just to state the obvious, this assumes that more extensive changes that would cause the removal of functionalities, without separate discussion for that removal, or prevent compiling and testing from source are not considered. On Mon, Jan 20, 2025 at 9:57 AM Andrew Purtell <apurt...@apache.org> wrote: > -1 for removing. spymemcached is only used in the test. Removing it > requires the only unit test for this module to be removed. Why? What is the > justification? Is there a CVE? > > I have tested the hbase-external-blockcache module, after fixing it in > HBASE-27796 <https://issues.apache.org/jira/browse/HBASE-27796> it does > plausibly work. It provides an option to externalize the block cache. We > were looking at it once at my work and still might consider it in the > future. Combined with, ok, other significant changes, you can imagine for > each table or namespace a separate external blockcache. This allows an > operator to allocate cache resources for a customer's table or namespace > and then the cache is dedicated to that customer and the costs of operating > it are easily accounted to the customer for charge-back or show-back. > > > On Mon, Dec 9, 2024 at 4:02 AM Istvan Toth <st...@apache.org> wrote: > >> Hi! >> >> The HBase assembly currently includes spymemcached. >> >> Memcached is used as the reference implementation of an external block >> cache in hbase-external-blockcache. >> >> However, the memcached dependency is marked as optional, which suggests >> that it was not meant to be included out of the box in the binary >> distribution. >> >> Also, the last release of the spymemcached java library was back in 2017. >> >> I propose removing the spymemcached JAR from the assembly. >> Those who still wish to use memcached external block cache support can >> provide the jar separately. >> >> What do you think ? >> Do you know anyone who uses HBase with memcached ? >> >> Istvan >> > > >
