> On Feb. 20, 2015, 10:19 p.m., Vinod Kone wrote:
> > src/authentication/cram_md5/authenticator.cpp, line 449
> > <https://reviews.apache.org/r/27760/diff/17/?file=869278#file869278line449>
> >
> >     Shouldn't this be protected by once() to avoid 2 different threads 
> > loading secrets at the same time?
> 
> Till Toenshoff wrote:
>     That would render our tests broken (those that reset the credentials). 
> The concurrency is covered by a Lock within that SASL aux plugin code.
> 
> Till Toenshoff wrote:
>     Let me know if this is ok, please.
> 
> Vinod Kone wrote:
>     Sorry, I don't think I follow. Can you elaborate on what specific tests 
> fail and why?
> 
> Till Toenshoff wrote:
>     Our tests all run within the same OS-process. A ONCE-gatekeeper on 
> credential loading within this process would indeed allow this only a single 
> time. The CRAM-MD5 tests do attempt to re/load the credentials; see 
> cram_md5_authentication.cpp #95, #140, ... 
>     These tests make sense given that we want to test the behavior of the 
> authenticator/authenticatee when using non matching credentials.
> 
> Vinod Kone wrote:
>     I don't see them reloading out of band. In other words, before your patch 
> we used to call secrets::load() directly from tests, which I agree has thread 
> safety issues if secrets::load() itself is not protected. But now, with your 
> patch, all the loading happens via Authenticator->initialize(). So I'm trying 
> to understand why the protection in Authenticator initialize is not enough. 
> Sorry, if I'm mising something.

I added some comment that should help explaining this rather complicated issue, 
as we had discussed on IRC. Assuming that this covers the issue, I will now 
mark it as "fixed".


- Till


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27760/#review73310
-----------------------------------------------------------


On March 5, 2015, 7:22 p.m., Till Toenshoff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27760/
> -----------------------------------------------------------
> 
> (Updated March 5, 2015, 7:22 p.m.)
> 
> 
> Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-2050
>     https://issues.apache.org/jira/browse/MESOS-2050
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The initial design and implementation of the authenticator module interface 
> caused issues and was not optimal for heavy lifting setup of external 
> dependencies. By introducing a two fold design, this has been decoupled from 
> the authentication message processing. The new design also gets us back on 
> track to the goal of makeing SASL a soft dependency of mesos.
> 
> 
> Diffs
> -----
> 
>   include/mesos/authentication/authenticator.hpp f66217a 
>   src/Makefile.am d299f07 
>   src/authentication/cram_md5/authenticator.hpp c6f465f 
>   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
>   src/authentication/cram_md5/auxprop.hpp b894386 
>   src/authentication/cram_md5/auxprop.cpp cf503a2 
>   src/master/master.hpp 3c957ab 
>   src/master/master.cpp 68ca19a 
>   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
> 
> Diff: https://reviews.apache.org/r/27760/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Reply via email to