POST requests give connection time out error when accessed from dispacther

[srinivasc110177]

Hi,

I am using CQ5.6.1.Could  some  one point out what  could be  reason login does not  maintain the session using dispacther but works when hitting cq5 instance directly

When user  log using  cq form through dispatcher.Then after some random hits the page session which is tracked using  a cookie is lost and the  user is again taken to login page with reason as j_reason=session_timed_out in the url.

I see that the request is coming to individual cq  pub instance.

The  same login mechanism  works without any issues when accessing via direct cq5 publish instance

We  have used 

http://sling.apache.org/documentation/the-sling-engine/authentication/authentication-authenticationh...

were we have used 

RememberAuthenticationHandler implements AuthenticationHandler, AuthenticationFeedbackHandler  {}

It hits the extractCredentials method  and  then hits authenticationFailed method not sure  what  is the  reason

In  the  dispachter.any the below setting  is done

 # Hostname globbing for farm selection (virtual domain addressing)
    /virtualhosts
      {
        "www.abc.com/products/abc/*"
        
}
     /sessionmanagement
       {
        /directory "/appl/webcache/session"
        /header "Cookie:login-token"
        /header "Cookie:remember-me"
        /timeout "300"
       }
    # The load will be balanced among these render instances
    /renders
      {
        /rend01
        {
        # Hostname or IP of the render
        /hostname "abc1.com"
        # Port of the render
        /port "4503"
        # Connect timeout in milliseconds, 0 to wait indefinitely
        /timeout "6000"
        }
      /rend02
       {
       /hostname "abc2.com"
       /port "4503"
       /timeout "6000"
      }

[Jörg_Hoh]

Hi,

Your dispatcher is balancing between 2 instances, so depending on which publish the session has been opened, the authentication cookie is either known or not. So it's a classic loadbalancing problem; from what I know this problem cannot be solved with the dispatcher (it cannot loadbalance based on cookie values), so you have to switch to a dedicated loadbalancer.

Jörg

[srinivasc110177]

Hi,

Do u mean that we just need to have one single instance with dispatcher/load balancer  mapped to it for this.Could you provide some samples if any will be helpfull

I have added in dispacther.any

/stickyConnections {

/paths {
"/content/products/abc"
}
}
 

Thanks

[Jörg_Hoh · Accepted solution]

Hi,

I don't know if I understood your question right...

The dispatcher has some basic loadbalancing strategy, but I've never used it. I don't know how reliable it works with sticky sessions / persistent sessions, but I can imagine, that it sometimes switches. I rather use a dedicated loadbalancer and do a 1:1 connection between dispatcher and publish instance, and put the loadbalancer in front of it.

I discussed this on https://cqdump.wordpress.com/2015/01/12/connecting-dispatchers-and-publishers/

kind regards,
Jörg

[srinivasc110177]

Thanks for the link you provide it was a useful information.

i have added the dispatcher,any setting could you provide  input for the below on stickyconnections

/stickyConnections {

/paths {
"/content/products/abc"
}

 with current dispatcher setting it does not work as expected as the request moves on to both the cq publish instance randomly where as it must stay on single cq instance for each login user.As per the currently investigation with current dispatcher setting it does not work as expected as the request moves to both the cq publish instance randomly where as it must stay on single cq instance for each login user.

[srinivasc110177]

Thanks we solved the problem for CQ5.6.1

We noticed that the dispatcher.any configuration on primary cq for render01 was pointing to node1 and on secondary render01 was pointing to node2,when this was rectified and made to point to same node then it started working correctly.

Also made the below changes and found in the cookies renderid was also getting stored on the client browser.I believe that dispatcher uses this cookie to find which node it must access

/stickyConnections {

/paths {
"/"
}