Yeah the amount of logging on that class seems to be pretty minimal :-)

I added the following logger to log4j.xml:

    <logger name="org.jasig.cas.support.saml" additivity="true">
        <level value="TRACE" />
        <appender-ref ref="cas" />
    </logger>

and got the following when I logged in to Google:
2014-12-11 11:45:54,256 DEBUG
[org.jasig.cas.support.saml.web.support.SamlArgumentExtractor] -
<Extractor did not generate service.>
2014-12-11 11:45:54,293 DEBUG
[org.jasig.cas.support.saml.web.support.GoogleAccountsArgumentExtractor]
- <Extractor generated service for:
https://www.google.com/a/demo.case.edu/acs>
2014-12-11 11:45:55,660 DEBUG
[org.jasig.cas.support.saml.web.support.SamlArgumentExtractor] -
<Extractor did not generate service.>
2014-12-11 11:45:55,667 DEBUG
[org.jasig.cas.support.saml.web.support.GoogleAccountsArgumentExtractor]
- <Extractor generated service for:
https://www.google.com/a/demo.case.edu/acs>

I could turn the authentication logger up to TRACE as well I suppose,
but that is going to add a whole lot of data to have to sift through to
the logs.

On 12/10/14 3:53 PM, Misagh Moayyed wrote:
>
> Ouch. I don’t see any explicit log statements, at least not in 4.0 but
> one thing you can do is turn up TRACE levels for
> org.jasig.cas.support.saml
>
> That should tell you everything.
>
>  
>
> I’ll see if I can add some extra log statements.
>
>  
>
> *From:*David A. Kovacic [mailto:d...@case.edu]
> *Sent:* Wednesday, December 10, 2014 1:17 PM
> *To:* cas-user@lists.jasig.org
> *Subject:* Re: [cas-user] Rapid Memory Consumption and Interpreting
> Heap Dump
>
>  
>
> Does anyone know what I would need to do to be able to log the actual
> SAML transactions?  Is there any way to actually do that?  We have
> isolated this issue to only logins to Google and only under certain
> conditions when something seems to start looping and generating STs
> rapidly.  We are trying to isolate the conditions under which the loop
> starts. 
>
> It would be helpful to actually see the SAML transactions being
> generated so we could begin to get a handle on what Google apps is
> being referenced and if Google is returning any errors or not
> (although Google claims valid logins).
>
> On 12/6/14 9:11 AM, Marvin Addison wrote:
>
>         Second, the massive number of  STs are being created on only
>         one server (we can tell by the host name in the logged ST) but
>         the OTHER SERVER is where the memory is growing out of bounds.
>
>      
>
>     I'm still working through this thread, but I wanted to point out
>     that the other is hurting likely because of load balancer session
>     affinity. Recall that ticket validation is a back-channel call,
>     and the network source differs from that of the user's browser. In
>     our environment, services typically get stuck on one node causing
>     hot spots. This is because the service is validating tickets
>     frequently enough that the session affinity timeout never kicks in.
>
>      
>
>     M
>
>      
>
>     -- 
>
>     You are currently subscribed to cas-user@lists.jasig.org 
> <mailto:cas-user@lists.jasig.org> as: d...@case.edu <mailto:d...@case.edu>
>
>     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 
> <mailto:cas-user@lists.jasig.org> as: mmoay...@unicon.net 
> <mailto:mmoay...@unicon.net>
> 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: d...@case.edu
> 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

Reply via email to