You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@bookkeeper.apache.org by GitBox <gi...@apache.org> on 2018/03/01 05:53:48 UTC

[GitHub] jvrao commented on issue #570: Multiple active entrylogs

jvrao commented on issue #570: Multiple active entrylogs
URL: https://github.com/apache/bookkeeper/issues/570#issuecomment-369481969
 
 
   @ivankelly @sijie @reddycharan Thnks a lot for this great conversation.  While it is nice to discuss ASF requirements for a pull request and the level of design discussions on the community email, the real crux comes down to the technical merit of the patch. The last thing any of us wanted to do is to commit buggy and badly designed code. We must not have any durability issues, after all, we are the persistent layer of many services above us. 
   
   If I can summarize @ivankelly's concerns:
   
   1. This is a large patch and is difficult to review. @ivankelly  while I agree that this is not a good practice, but for historical reasons, it ended up this way. We may not retroactively fix this unless @reddycharan thinks it is easy. So my request is to take some time and review this for now, and we can set up strict guidelines for future.  Also, the community is lot active now (after Streamlio) before it was mostly silos.
   
   2. It is a Highrisk patch as it touches the most sacred persistence layers. We must absolutely review/test to gain confidence in the patch. I request more eyes on this. Should add more tests and run with fault injection. Maybe an opportunity to vet test cases. 
   
   3. Abstraction is not in the right place. As @reddycharan  and @sijie  explained we went through many discussions around this. Charan even tried prototyping the abstraction at the ledger manager level. That ended up much more complicated than this. And some of the discussion was referred by email links given by @reddycharan 
   
   Entry log per extent is very important for Salesforce for various reasons and I bet it will be essential to any use case which uses SSDs and doesn't have too many writable ledgers/ bookie at any given time.
   Moreover, it makes lot easy to implement storage tiering.
   
   We can have another meeting if needed, and my request is to move forward on the pure technicality of the patch rather than design preferences.  
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services