Login bug in the web serving benchmark? about cloudsuite

[Hnefi]

Hey J-Lee:
Thanks for opening this. One thing I wanted to bring up w. you is that the docker version you were using is an "edge" release and not a stable one. I just am looking into it now to repro your result with the edge release

[Hnefi]

Hi again!

I have more questions about the issue that you opened. You say that the fetched page does not contain the substring? However, the returned URL is checked for the string, as you also saw from looking at the code.

In this bug, you are saying that you found a situation where the returned URL does not contain the string "You have been logged in"? If this is correct, the benchmark should fail every time?

[j-1-lee]

Hi Mark,

Yes, the returned URL (i.e., fetched page) did not have the string "You have been logged in".
A little more detail on what I went through:

1. The benchmark seems to generate the users OK (usergen.jar/UserGenerator.java), but the actual runs fail due to login failures. I double-checked that we are using correct usernames and passwords -- we issue login requests using the ids/pws we've generated during usergen.

2. Inspected the codes and outputs (fetched pages) of the usergen and the driver.

<UserGenerator.java / createUsers()>
sb = http.fetchURL(hostURL+"/action/login", loginPostRequest, headers);
// printed sb, nothing special
sb = http.fetchURL(hostURL+"/activity");
// printed sb, found "You have been logged in" string
==> Don't know why it fetches /activity right after the login request, but this seems to do the trick of showing the "logged in" string.

<Web20Driver.java / doLogin>
StringBuilder sb = thisClient.getHttp().fetchURL(hostUrl + LOGIN_URL, postRequest, headers);
==> sb does not have the "logged in" string and the benchmark fails. Why not use sb = http.fetchURL(hostURL+"/activity"); to check the login status?

3. Problem solved

And thanks for letting me know of the docker version. I should probably switch to a more stable release.

Thanks,
Jaewon

[rahulketch]

Hi,

Thanks for the details. #142 fixes the issue.