Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

POST requests give connection time out error when accessed from dispacther

Avatar

Level 4

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"
      }

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

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

View solution in original post

5 Replies

Avatar

Employee Advisor

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

Avatar

Level 4

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

Avatar

Correct answer by
Employee Advisor

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

Avatar

Level 4

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.

Avatar

Level 4

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 {
"/"
}