Sorry folks I just realized this was intended for the cas user list.
Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 907-450-8320 Fairbanks, Alaska 99775 [email protected] | www.alaska.edu/oit/ On Thu, Sep 5, 2013 at 3:43 PM, Linda Toth <[email protected]> wrote: > I also should mention that our team has not been interested in using > tomcat 8443, but instead uses 443. Personally, I do not see a special > advantage to doing it this way, but there it is. I am forwarding how our > SA suspects the socket failures are occurring: > > *Apache's default timeout is 300 seconds. Red Hat reduces the connection > timeout for Apache to 60 seconds. Most users aren't going to wait more > than 10 seconds, anyway. If tomcat does not respond to Apache before that > timeout, Apache will close the connection and log the timeout expired > messages David mentioned. When tomcat tries to respond after Apache has > closed the connection it will throw a SocketException with the message > "Broken Pipe". > * > > > Linda Toth > University of Alaska - Office of Information Technology (OIT) - Identity > and Access Management > 910 Yukon Drive, Suite 103 > 907-450-8320 > Fairbanks, Alaska 99775 > [email protected] | www.alaska.edu/oit/ > > > > On Thu, Sep 5, 2013 at 2:46 PM, Linda Toth <[email protected]> wrote: > >> Good afternoon >> >> We have recently implemented SSO for Banner 8 via CAS. Our LDAP >> repository is AD. We are running one CAS server and are now in the process >> of load testing the capability of CAS to match the load volume tested when >> using only Banner BEIS authentication. >> >> The tests are set up through WebLOAD. The tests are designed by setting >> a fixed number of virtual users who attempt to log in at the same time. >> The tests start at 100, then 200, 250, 275, and 300. At 275 simultaneous >> attempts to login, the WebLOAD tool receives many Internal 500 errors. >> >> Some on the team assess the situation as an indication that CAS can not >> keep up with the load. Others suspect the tool itself, which must now >> contend with browser redirects while simulating a high volume of users. >> >> Which ever the case, I do know that there are no issues in volume >> connections to AD. All LDAP authentication steps are made. >> >> The Socket failure messages take the following form, but not always at >> the exact same juncture: >> >> 2013-09-05 07:40:39,174 DEBUG >> [org.jasig.cas.web.support.SamlArgumentExtractor] - Extractor generated >> service for: >> https://<server>.alaska.edu:443/<<https://beisregx.alaska.edu/ssomanager/c/SSB> >> target> >> 2013-09-05 07:40:39,178 ERROR >> [org.jasig.cas.web.view.Saml10SuccessResponseView] - >> ClientAbortException: java.net.SocketException: Broken pipe >> >> 2013-09-05 07:40:42,235 ERROR >> [org.jasig.cas.web.view.Saml10SuccessResponseView] - >> ClientAbortException: java.net.SocketException: Broken pipe >> >> Ellucian, when Atlassian, indicated this error was not fatal, however, >> our team is seeking a definite assurance that a single CAS server can >> manage such high volumes during peak times when login attempts can exceed >> 2000 in the first five minutes. >> >> Is CAS incapable of accepting more than 250 simultaneous login attempts >> without failure? If not, how have teams tested the load so that it met >> load requirements? >> >> Linda >> >> -- >> >> Linda Toth >> University of Alaska - Office of Information Technology (OIT) - Identity >> and Access Management >> 910 Yukon Drive, Suite 103 >> 907-450-8320 >> Fairbanks, Alaska 99775 >> [email protected] | www.alaska.edu/oit/ >> >> > -- 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-dev
