httpclient async feature

[Hal Deadman]

I was looking at the changes in HttpClient slated for version 3.3.3 and I like the idea of doing the single log out HTTP calls asynchronously because   there is a performance monitoring benchmark running against the site I support that over-emphasizes logout performance. I haven't played with the ExecutorService but they seem to have a shutdown method and this one isn't being called anywhere. I know webapps often suffer from classloader memory leaks and if something prevents the classloader from being garbage collected after a hot-deploy I worry that maybe the threads in the ExecutorService's associated thread pool might hang around along with the classes (since it is stored in static variable). At a minimum it might be worth exposing a static shutdown method so that it could be called in an application listener (on undeploy).

On the subject of HttpClient, I would like to request that isValidEndPoint() method log the URL being invoked when an IOException is caught. I am currently getting socket exceptions and it would be nice to be able to turn on debug logging and see which URL they go with. I know this method is used to pass proxy granting tickets to other apps and those might not be something you would want to show up in a log file so if the parameters are excluded that is fine. Also, it could be logged at the debug level so that people could turn it off if they don't want to see it. 

I am also using the JPATicketRegistry with Oracle and getting lots of deadlock detected exceptions in the logs. We customized the webapp to handle the errors and there doesn't seem to be performance penalty b/c Oracle detects the problem quickly, but it is nice to see that get fixed. I am looking forward to the 3.3.3 release. 

Thanks, Hal

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia-2]

Good catch.  I added a destroy method to the HttpClient and made sure all the beans were injected with a Spring managed instance of HttpClient so that destroy would be guaranteed to be called (which calls the shutdown method).  I'll test it out tomorrow.  The 3.3.3 release will either be Thursday or Friday.

Cheers,
Scott

On Wed, Jun 24, 2009 at 4:06 PM, Hal Deadman <[hidden email]> wrote:

I was looking at the changes in HttpClient slated for version 3.3.3 and I like the idea of doing the single log out HTTP calls asynchronously because   there is a performance monitoring benchmark running against the site I support that over-emphasizes logout performance. I haven't played with the ExecutorService but they seem to have a shutdown method and this one isn't being called anywhere. I know webapps often suffer from classloader memory leaks and if something prevents the classloader from being garbage collected after a hot-deploy I worry that maybe the threads in the ExecutorService's associated thread pool might hang around along with the classes (since it is stored in static variable). At a minimum it might be worth exposing a static shutdown method so that it could be called in an application listener (on undeploy).

On the subject of HttpClient, I would like to request that isValidEndPoint() method log the URL being invoked when an IOException is caught. I am currently getting socket exceptions and it would be nice to be able to turn on debug logging and see which URL they go with. I know this method is used to pass proxy granting tickets to other apps and those might not be something you would want to show up in a log file so if the parameters are excluded that is fine. Also, it could be logged at the debug level so that people could turn it off if they don't want to see it. 

I am also using the JPATicketRegistry with Oracle and getting lots of deadlock detected exceptions in the logs. We customized the webapp to handle the errors and there doesn't seem to be performance penalty b/c Oracle detects the problem quickly, but it is nice to see that get fixed. I am looking forward to the 3.3.3 release. 

Thanks, Hal

-- 
You are currently subscribed to [hidden email] as: [hidden email]


To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

Hal, thanks for taking the time to carefully review some of the fixes
slated for 3.3.3.

> I am also using the JPATicketRegistry with Oracle and getting lots of
> deadlock detected exceptions in the logs. We customized the webapp to handle
> the errors and there doesn't seem to be performance penalty b/c Oracle
> detects the problem quickly, but it is nice to see that get fixed. I am
> looking forward to the 3.3.3 release.

We'd be very interested in your commenting on
http://www.ja-sig.org/issues/browse/CAS-782 about your experience with
the fix for that issue that should appear in 3.3.3.  External
verification is good even if it's after the fact.

M

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Hal Deadman]

We'd be very interested in your commenting on
http://www.ja-sig.org/issues/browse/CAS-782 about your experience with
the fix for that issue that should appear in 3.3.3.  External
verification is good even if it's after the fact.

I will try out trunk today although I don't have a good load test to reliably re-create the problem. We have a CAS authenticated portal (BEA ALUI Portal) and on the landing page after login there is a portlet that authenticates to a CAS enabled webmail application in an i-frame. The webmail app gets a proxy granting ticket so it can authenticate via pam_cas to a cyrus IMAP server. If I logged out of the portal immediately after logging in, single-logout would sometimes be deleting the parent tickets while CAS was trying to insert child PGT tickets on behalf of the webmail app. There would either be a deadlock exception or a parent key not found exception. I don't think that was the only scenario where I saw errors but it was one case. 

I also have a custom ticket registry cleaner that does some stuff specific to our application but I also added an "enabled" property to the job bean which is set via an external property file so that the registry cleaner only runs on one server in the cluster (so both CAS servers aren't cleaning the same tickets at the same time). I switched my registry cleaner to use spring instead of quartz for scheduling but I could have achieved the same thing by using Quartz with a database backing it but I didn't feel like adding the Quartz tables. Quartz with a DB would have had the advantage of working even if one server in the cluster were down for a long period of time. 

Thanks, Hal

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev