Thanks Marvin and Scott. I'll try the Jmeter load run and let you know the outcome
** Now one more question i have is . The JPa tickey cleaner i have is scheduled to run at the same time in 3 nodes in cluster. Since its farm deployment all the configurations are same. Do you prefer it running from only one server ..Or running from different server at different timing. Thanks Kunju On Sat, Aug 14, 2010 at 11:37 AM, <[email protected]> wrote: > Just to add to Marvin's point: the default cleaner completely respects the > ticket expiration policy rules. A more efficient cleaner (I.e. One using > sql) may use some other criteria to do clean up. > > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Marvin Addison <[email protected]> > Date: Sat, 14 Aug 2010 11:31:13 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: [cas-user] Cas server with Jboss Cluster > > > There are lot questons coming up like ..Will it create locks .. > > JpaTicketRegistry relies on the database platform to handle locking > properly. The component simply creates reasonable transaction > boundaries in which the platform is expected to do locking. I can say > from experience with a few database backends, the performance and > capability varies greatly. I'd say Oracle handles locking best, > PostgreSQL worst, with SQL Server somewhere in the middle. > > > Is it dependable > > Yes > > > will it kill the servers with memory issues .. > > I assume you are asking whether it's a memory hog. Memory > requirements are very reasonable in most cases. There is one edge > case where memory usage can kill you: a rogue client requesting > tickets that are never validated. There's an application-side ticket > cleaner component that attempts to load all expired tickets into > memory then iterate over them deleting the expired ones. Obviously if > there are an immense number of expired tickets, you may experience an > OOM condition. We have only seen this in load testing under extreme > conditions where we purposely leave a large fraction of tickets > unvalidated to stress the ticket registry. You might consider running > the VT JMeter load test attached to > https://wiki.jasig.org/display/CASUM/Apache+JMeter if you have > concerns about this. Additionally, you should investigate services > management, https://wiki.jasig.org/display/CASUM/Services+Management, > to restrict authorized services to ones you have vetted. > > M > > -- > 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 > -- 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
