I think there are two items to consider here: 1. is how to do we make sure a misconfigured client doesn't denial of service a server (I thought some of our throttling stuff should have handled that, but maybe not?) 2. why is your specific client going nuts (is that user not found and it gets into a loop, etc.)
On Mon, Dec 8, 2014 at 12:30 PM, David A. Kovacic <d...@case.edu> wrote: > Actually if you read the docs, it describes how to rate-limit (throttle) > FAILED login attempts. What we are seeing is large numbers of > SUCCESSFUL logins, at least as evidenced by the large number of STs > generated, from the same user over a shortly period of time (thousands > in about an hour). > > On 12/2/14 7:23 PM, Trenton D. Adams wrote: > > It does have a way of rate limiting per user, check the docs. :D > > > > On 14-12-02 05:17 PM, Carl Waldbieser wrote: > >> Dave, > >> > >> How many logins? > >> We recently had a misconfugured cas client from a vendor almost fill > >> /var. It was tens of thousands of logins. > >> > >> It would be nice if cas had some way to rate limit ST and login requests > >> per user. > >> > >> Thanks, > >> Carl > >> > >> On Dec 2, 2014 3:26 PM, "David A. Kovacic" <d...@case.edu > >> <mailto:d...@case.edu>> wrote: > >> > >> I'm not sure how or where you would mark this as a singleton > >> instance - although if you go back to an actual Google web page > >> multiple times from the same browser session you reuse the ST if > >> that's what you mean. This actually looked like multiple logins > >> from a single user over the span of about 30 minutes. Not sure if > >> this was some poorly written webapp logging in several time or what. > >> > >> > >> On 12/2/14 1:32 PM, Erik-Paul Dittmer wrote: > >>> Rapid heap memory consumption (which are not garbage collected) > >>> *can* be caused by unfinished Spring Webflow flow sessions; this > >>> is something we have observed. However, when looking at your > >>> memory dump, the majority of the instances (and size) is being > >>> claimed by the GoogleAccountService. Perhaps this is not marked as > >>> a singleton instance? > >>> > >>> On Tue, Dec 2, 2014 at 6:38 PM, David A. Kovacic <d...@case.edu > >>> <mailto:d...@case.edu>> wrote: > >>> > >>> All, > >>> > >>> Yesterday evening one of our CAS 4.0.0 servers went from under > >>> a GB of heap usage to 3GB in a matter of about 10 minutes. > >>> The end result was that again the SSO service died (one server > >>> with a heap memory OoM error and the other trying to replicate > >>> the ehcache to the dead server. This was definitely not a > >>> memory leak issue as the servers had been restarted only > >>> earlier that morning, so they had only been up for about 17 > >>> hours or so. Out system monitors also indicated that the > >>> memory usage rather suddenly skyrocketed (over the course of > >>> about 20 minutes) so we suspect that the memory consumption is > >>> a symptom of some other issue. > >>> > >>> We have a heap dump but I am having a bit of trouble trying to > >>> analyze it with jvisualvm as I have never used the tool > >>> before. If I am interpreting the dump correctly, it appears > >>> that tickets only play a very small part of the overall memory > >>> usage (see screen shot). > >>> > >>> > >>> > >>> Has anyone heard or experienced anything like what we are > >>> seeing? This is becoming increasingly frustrating as every > >>> time we think we have the issues resolved and turn our > >>> attention elsewhere one server or the other crashes and takes > >>> the service down with it. > >>> > >>> Dave > >>> > >>> -- > >>> You are currently subscribed tocas-u...@lists.jasig.org > >>> <mailto:cas-user@lists.jasig.org> as:epditt...@digitalmisfits.com > >>> <mailto:epditt...@digitalmisfits.com> > >>> To unsubscribe, change settings or access archives, > >>> seehttp://www.ja-sig.org/wiki/display/JSG/cas-user > >>> > >>> > >>> > >>> > >>> -- > >>> Erik-Paul Dittmer > >>> T: +31 (0) 64 761 87 57 > >>> > >>> Visit us at http://www.digitalmisfits.com > >>> > >>> - - - - - - - - - - - - - - - - - - - - - - - - - - > >>> Digital Misfits does not accept any liability for any errors, > >>> omissions, delays of receipt or viruses in the contents of this > >>> message which arise as a result of e-mail transmission. > >>> -- > >>> You are currently subscribed tocas-u...@lists.jasig.org > >>> <mailto:cas-user@lists.jasig.org> as:d...@case.edu > >>> <mailto:d...@case.edu> > >>> To unsubscribe, change settings or access archives, > >>> seehttp://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> -- > >> You are currently subscribed tocas-u...@lists.jasig.org > >> <mailto:cas-user@lists.jasig.org> as:cwaldbie...@gmail.com > >> <mailto:cwaldbie...@gmail.com> > >> To unsubscribe, change settings or access archives, > >> seehttp://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> -- > >> You are currently subscribed to cas-user@lists.jasig.org as: > >> tre...@athabascau.ca > >> To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > > > > > > > > -- > > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
