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:[email protected]]
> *Sent:* Wednesday, December 10, 2014 1:17 PM
> *To:* [email protected]
> *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 [email protected]
> <mailto:[email protected]> as: [email protected] <mailto:[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]
> <mailto:[email protected]> as: [email protected]
> <mailto:[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
