merlimat commented on issue #1355: Remove as many Thread.sleep calls from REST 
   @mgodave This change doesn't solve the problem that the ugly 
`Thread.sleep()` was introduced as a workaround for.
   The problem is not the sync vs async ZK call (though sure, the async with 
response continuation is more efficient). 
   The real problem is that in ZK there is no read-your-write consistency by 
default. That is also aggravated by the fact the we have a cache for 
configuration/metadata that is updated with ZK watches.
   The particular instance of the problem typically manifest itself only in a 
test environment where there are multiple brokers and multiple ZK servers in 
the ensemble. 
   It goes like this: 
    * Create a partitioned topics --> create a z-node with the partitions info
    * Try to use the partitioned topic immediately after
       1. The request to check the partitioned topic metadata can go to a 
different broker
       2. That broker is connected to a different ZK server
       3. That ZK server is few steps behind the ZK quorum
       4. The partitioned topic metadata is not there in ZK
   The "good" solution would be to always do a ZK `sync()` before reading the 
partitioned topic metadata. That would ensure that we can actually read our 
previous write.
   The problem with that is that we have to do a ZK write (implied by `sync()`) 
and that we can never cache the info in broker.
   + @ivankelly if you have any other suggestion

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:

With regards,
Apache Git Services

Reply via email to