Sorry, I misread what you wrote as replication (its early here :-)). If you have sticky sessions enabled, can you confirm that they are really hitting the same server?
On Tue, Jun 12, 2012 at 8:39 AM, Ronen Itkin <[email protected]> wrote: > What do you mean replicated in this case? > > > > On Tue, Jun 12, 2012 at 3:26 PM, Scott Battaglia < > [email protected]> wrote: > >> Ronen, >> >> Do you know if the session is replicating quickly enough? (I don't >> actually know the best way to test this :-)) >> >> Cheers, >> Scott >> >> >> On Tue, Jun 12, 2012 at 8:18 AM, Ronen Itkin <[email protected]> wrote: >> >>> Scott - Actually I enabled a 'sticky session' option on the load >>> balancer - so as long as the session was not terminated by the cas server >>> itself, it should be always redirected to the same as. >>> >>> by the way when the load balancer has only one cas server in service it >>> works great! >>> When I add another cas server to the load balancer, those issues arises. >>> So is has to be something with the lb redirection - but what? :/ >>> >>> Leszek - Thanks! I dont want to give up on load sharing (yet :)). >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Jun 12, 2012 at 2:51 PM, Scott Battaglia < >>> [email protected]> wrote: >>> >>>> Spring Web Flow doesn't allow you to round robin your CAS requests >>>> unless you're using Tomcat session replication. Spring Web Flow holds its >>>> internal state in session (though you could write something that replaces >>>> that). >>>> >>>> Cheers, >>>> Scott >>>> >>>> >>>> On Tue, Jun 12, 2012 at 6:30 AM, Ronen Itkin <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I have implemented two cas 3.4.12 servers with jdbc support and JPA >>>>> ticket registration. >>>>> It worked great until I added a load balancer that redirects traffic >>>>> to one of the available cas servers (based on port availability - round >>>>> robin session redirection), >>>>> Actually it is Amazon's web services load balancer, AKA Elastic Load >>>>> Balancer. >>>>> It listens to port 8443 and forwards it to the same port (8443) >>>>> towards one on the available cas servers. >>>>> Cas login page appears and when I am trying to log in it just reloads >>>>> the cas login screen again - without mentioning any problems, it repeats >>>>> itself for a few login tries and after few attempts I get the following >>>>> notification from my browser: >>>>> >>>>> --- >>>>> Authorization Required >>>>> >>>>> This server could not verify that you are authorized to access the >>>>> document requested. Either you supplied the wrong credentials (e.g., bad >>>>> password), or your browser doesn't understand how to supply the >>>>> credentials >>>>> required. >>>>> ------------------------------ >>>>> Apache/2.2.16 (Ubuntu) Server at x.x.x.x..x.x.compute-1.amazonaws.comPort >>>>> 80 >>>>> >>>>> --- >>>>> >>>>> >>>>> *Cas.log shows:* >>>>> >>>>> >>>>> 2012-06-12 10:11:22,848 INFO >>>>> [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceTicket [ >>>>> ST-1-SCiu0IAOcYwAcMd3ElRi-ec2-xx-xx-xxx-xxx.compute-1.amazonaws.com] >>>>> has expired. >>>>> 2012-06-12 10:11:22,851 INFO >>>>> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit >>>>> trail record BEGIN >>>>> ============================================================= >>>>> *WHO: audit:unknown* >>>>> WHAT: >>>>> ST-1-SCiu0IAOcYwAcMd3ElRi-ec2-xx-xx-xxx-xxx.compute-1.amazonaws.com >>>>> ACTION: SERVICE_TICKET_VALIDATE_FAILED >>>>> APPLICATION: CAS >>>>> WHEN: Tue Jun 12 10:11:22 UTC 2012 >>>>> CLIENT IP ADDRESS: 10.210.218.98 >>>>> SERVER IP ADDRESS: 10.211.173.168 >>>>> ============================================================= >>>>> >>>>> So I guess it acts that way because it cant recognize the user that is >>>>> attempting to login because normally is should write: >>>>> >>>>> WHO: [username: ronen] >>>>> >>>>> Does someone has an Idea of why it can happen while accessing Cas >>>>> trough a load balancer? >>>>> If I am accessing both cas servers directly and try to simply >>>>> authenticate it works great!! only when accessing cas trough the load >>>>> balancer it happens occasionally. >>>>> (It does work sometimes - means that the ssl certificate of Cas's >>>>> tomcat machine was successfully imported to the load balancer and basic >>>>> configurations are fine) >>>>> >>>>> >>>>> Thanks!! >>>>> >>>>> >>>>> >>>>> -- >>>>> * >>>>> Ronen Itkin* >>>>> Taykey | www.taykey.com >>>>> >>>>> -- >>>>> You are currently subscribed to [email protected] as: >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> To unsubscribe, change settings or access archives, see >>>>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>>>> >>>>> >>>> -- >>>> You are currently subscribed to [email protected] as: >>>> [email protected] >>>> >>>> >>>> >>>> >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>>> >>>> >>> >>> >>> -- >>> * >>> Ronen Itkin* >>> Taykey | www.taykey.com >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> >>> >>> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> >> -- >> You are currently subscribed to [email protected] as: [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > > > -- > * > Ronen Itkin* > Taykey | www.taykey.com > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
