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
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"
}
Solved! Go to Solution.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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 {
"/"
}
Views
Replies
Total Likes