Hi Leonardo, Thanks a lot for your help. We were able to fix the issue. You can pull the new images. Additionally, you can take a look at the changes here:
https://github.com/ParsaLab/cloudsuite/commit/65644f3195c9e327afd3ff370748a573d0f7f984 <https://github.com/ParsaLab/cloudsuite/commit/65644f3195c9e327afd3ff370748a573d0f7f984> Thanks again! Regards, Javier > On 04 Mar 2016, at 18:59, Leonardo Piga <[email protected]> wrote: > > Hi Javier, > > I found a solution. > > Faban is not following the third redirect chain to the activity. So I > forced it manually. The following code does the trick and worked for > me. > Now my next task is to try to saturate one one the components. > > public void doLogin() throws Exception { > boolean success = false; > long loginStart = 0, loginEnd = 0; > context.recordTime(); > logger.fine(context.getThreadId() + " : Doing operation: doLogin with" > + thisClient.getUsername()); > > /* > * To do the login, To login, we need four parameters in the POST query > * 1. Elgg token 2. Elgg timestamp 3. user name 4. password > */ > String postRequest = "__elgg_token=" + thisClient.getElggToken() > + "&__elgg_ts=" + thisClient.getElggTs() + "&username=" > + thisClient.getUsername() + "&password=" > + thisClient.getPassword(); > > for (String url : LOGIN_URLS) { > thisClient.getHttp().readURL(hostUrl + url); > } > > Map<String, String> headers = new HashMap<String, String>(); > headers.put("Accept", > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"); > headers.put("Accept-Language", "en-US,en;q=0.5"); > headers.put("Accept-Encoding", "gzip, deflate"); > headers.put("Referer", hostUrl + "/"); > headers.put("User-Agent", > "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) > Gecko/20100101 Firefox/33.0"); > headers.put("Content-Type", "application/x-www-form-urlencoded"); > > thisClient.getHttp().readURL(hostUrl + LOGIN_URL, > postRequest, headers); > StringBuilder sb = thisClient.getHttp().fetchURL(hostUrl + > ACTIVITY_URL); > > updateElggTokenAndTs(thisClient, sb, true); > printErrorMessageIfAny(sb, postRequest); > if (sb.toString().contains("You have been logged in")) { > logger.fine("Successfully logged in: "+thisClient.getUsername()); > } else { > logger.fine("!!!!!!!!!!!!!!!!!! Failed to log in > :"+thisClient.getUsername()+"!!!!!!!!!!!!!!!!!!!!!"); > throw new RuntimeException(sb.toString()); > } > thisClient.setLoggedIn(true); > thisClient.setClientState(ClientState.LOGGED_IN); > success = true; > > context.recordTime(); > > if (success) > elggMetrics.attemptLoginCnt++; > } > Leonardo > > > On Thu, Mar 3, 2016 at 10:54 PM, Leonardo Piga <[email protected]> > wrote: >> Hi Javier, >> >> I got a clue. It seems a problem with Faban driver. >> >> I believe that Faban is not accessing the /activity page after login. >> >> Here is the nginx log when login using chrome: >> [04/Mar/2016:01:47:20 +0000] "POST /action/login HTTP/1.1" 302 5 >> "http://web_server:8080/"; "Mozilla/5.0 (X11; Linux x86_64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 >> Safari/537.36" >> [04/Mar/2016:01:47:21 +0000] "GET / HTTP/1.1" 302 5 >> "http://web_server:8080/"; "Mozilla/5.0 (X11; Linux x86_64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 >> Safari/537.36" >> [04/Mar/2016:01:47:21 +0000] "GET /activity HTTP/1.1" 200 7746 >> "http://web_server:8080/"; "Mozilla/5.0 (X11; Linux x86_64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 >> Safari/537.36" >> [04/Mar/2016:01:47:22 +0000] "GET /elggchat_scroll.js HTTP/1.1" 404 >> 5502 "http://web_server:8080/activity"; "Mozilla/5.0 (X11; Linux >> x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 >> Safari/537.36" >> [04/Mar/2016:01:47:22 +0000] "GET /framework/wall/init.js HTTP/1.1" >> 404 5502 "http://web_server:8080/activity"; "Mozilla/5.0 (X11; Linux >> x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 >> Safari/537.36" >> >> Here is the nginx log when login using Faban: >> [04/Mar/2016:01:51:05 +0000] "POST /action/login HTTP/1.1" 302 5 >> "http://web_server:8080/"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; >> rv:33.0) Gecko/20100101 Firefox/33.0" >> [04/Mar/2016:01:51:06 +0000] "GET / HTTP/1.1" 200 7892 "-" "Java/1.7.0_95" >> [04/Mar/2016:01:51:07 +0000] "GET >> /_graphics/icons/user/defaulttopbar.gif HTTP/1.1" 200 599 "-" >> "Java/1.7.0_95" >> [04/Mar/2016:01:51:07 +0000] "GET /_graphics/toptoolbar_background.gif >> HTTP/1.1" 200 2028 "-" "Java/1.7.0_95" >> [04/Mar/2016:01:51:07 +0000] "GET >> /mod/reportedcontent/graphics/icon_reportthis.gif HTTP/1.1" 200 570 >> "-" "Java/1.7.0_95" >> >> Note that Faban does not try to access the activity and also the >> redirection is returning 200 where in the browser it returns 302. I >> suspect there is a third redirection to /activity but Faban is not >> able to do that >> In the browser the login page is redirected to >> http://web_server:8080/activity and that page has the "You have been >> logged in". >> >> Thanks for looking at this >> Leonardo >> >> >> On Thu, Mar 3, 2016 at 7:45 PM, Javier Picorel <[email protected]> >> wrote: >>> Hi Leonardo, >>> >>> Thanks a lot for pointing that out! It seems that we broke something in our >>> last update :(. We are currently trying to figure out what. As soon as we >>> have news, we’ll let you know. >>> >>> Regards, >>> Javier >>> >>>> On 03 Mar 2016, at 21:50, Leonardo Piga <[email protected]> wrote: >>>> >>>> Hi All, >>>> >>>> Still debugging the Web Server and I figured out the logins are never >>>> successful. >>>> >>>> The back-end works well, however the page returned to the faban driver >>>> needs to interpret a javascript to print the "You have been logged in" >>>> message. Faban is not doing that, in this way, that message is never >>>> seen by faban you don't have a way to figure out if the login was >>>> successful. Becase this is never there Faban assumes that login fails >>>> and returns >>>> >>>> I think this is a big problem as state of the Faban driver never >>>> changes to LOGGED_IN and all other operations (e.g., addFriend, >>>> sendChatMessage, etc) never goes to server. So the benchmark is not >>>> benchmarking anything. >>>> >>>> I tried to find a way to fix that, but I still couldn't find way. >>>> People should not use this at the way that is delivered because the >>>> only operation that goes to the web sever is login. Others are never >>>> executed. >>>> >>>> I will see if I can come up with a solution, but I want to make people >>>> aware and see if others are working on a fix. >>>> >>>> Thanks, >>>> -- >>>> Leonardo >>>
