Re: [DISCUSS] Retire BKJM from trunk?

If I remember correctly, Huawei also adopted QJM component. I hope @Vinay might have discussed internally in Huawei before starting this e-mail discussion thread. I'm +1, for removing the bkjm contrib from the trunk code. Also, there are quite few open sub-tasks under HDFS-3399 umbrella jira,

Re: [DISCUSS] Retire BKJM from trunk?

+ Rakesh and Uma Rakesh and Uma might have a better idea on this. I think Huawei was using it when Rakesh and Uma worked there. - Sijie On Wed, Jul 27, 2016 at 12:06 PM, Chris Nauroth wrote: > I recommend including the BookKeeper community in this discussion. I’ve >

Re: [DISCUSS] Retire BKJM from trunk?

I recommend including the BookKeeper community in this discussion. I’ve added their user@ and dev@ lists to this thread. I do not see BKJM being used in practice. Removing it from trunk would be attractive in terms of less code for Hadoop to maintain and build, but if we find existing users

Re: Improving recovery performance for degraded reads

Hi Roy, (a) In your last email, I am sure you meant => "... submitting read requests to fetch "any" (instead of all) the 'k' chunk (out of k+m-x surviving chunks) ? Do you have any optimization in place to decide which data-nodes will be part of those "k" ? Answer:- I hope you know

[DISCUSS] Retire BKJM from trunk?

Hi All, BKJM was Active and made much stable when the NameNode HA was implemented and there was no QJM implemented. Now QJM is present and is much stable which is adopted by many production environment. I wonder whether it would be a good time to retire BKJM from trunk? Are there