As per Guava version conflict, we should be able to shade the dependency to another package, maybe with the whole asynchbase together. Guava versions have been the PITA for many other projects too, and usually got avoided this way.
If we can avoid the Asynchbase+Guava issue by shading them and the only interesting reason left to switch is the benchmark, it might not worth going back to the blocking API as it will require a whole new threading design. Sincerely, Jong Wook Sent from my iPhone > On Apr 19, 2016, at 9:01 PM, DO YUNG YOON <sho...@gmail.com> wrote: > > Hi All. > > Since implementing storage becomes easier(I believe), I think it is good to > have HBaseStroage which use HBase's native client. > The reason I brought up this is following. > > 1. in some environment, especially specific Hadoop and Spark cluster > distribution, > s2core have guava version conflict which comes from asynchbase. > - Many cases it is necessary to process stream of edges and write into > HBase directly on streaming processing. > - Currently, there is no way to specify version to avoid above problem. > With Native HBaseClient, users will be select right version for there > environment. > 2. It would be fun to run benchmark on these two client. > > any feedback would be appreciated. > > Best Regards. > DOYUNG YOON
