[09:01:21 CDT(-0500)] <sjungling> @EricDalquist rolled out your LDAP pooling config about an hour ago
[09:01:47 CDT(-0500)] <sjungling> LDAP admin is reporting that things look pretty clean. no deferred operations, but our traffic will be pretty low for the next 90 minutes.
[09:01:55 CDT(-0500)] <EricDalquist> cool
[09:01:58 CDT(-0500)] <sjungling> so, many thanks for your help yesterday on that
[09:02:00 CDT(-0500)] <EricDalquist> yeah
[09:02:03 CDT(-0500)] <EricDalquist> hopefully it helps
[09:02:09 CDT(-0500)] <sjungling> we are still noticing that it's making multiple LDAP queries per user
[09:02:11 CDT(-0500)] <sjungling> even with caching
[09:02:26 CDT(-0500)] <sjungling> leading theory is that it's doing 1 per PAGS group
[09:02:39 CDT(-0500)] <EricDalquist> well it would be making one call to person directory per pags group
[09:02:57 CDT(-0500)] <EricDalquist> but the caching really should be resulting in only one LDAP query
[09:03:01 CDT(-0500)] <sjungling> right… but why caching isn't catching that…
[09:03:06 CDT(-0500)] <EricDalquist> that I don't know
[09:04:08 CDT(-0500)] <sjungling> we're wondering if upon initial login the cache hasn't finished saving
[09:04:37 CDT(-0500)] <sjungling> cause after initial login we're not seeing any more requests to LDAP
[09:05:02 CDT(-0500)] <EricDalquist> it should be cached immediately after the first query is complete
[09:05:07 CDT(-0500)] <sjungling> hrm
[09:05:39 CDT(-0500)] <sjungling> i see 30% effectiveness on my ldap cache and 75% on merged attributes
[10:39:07 CDT(-0500)] <drewwills> hey folks – is the maven-sass-plugin completely wired-in and working in uP 4.0.x?
[10:39:17 CDT(-0500)] <drewwills> it looks like it may be
[10:40:50 CDT(-0500)] <EricDalquist> yes
[10:40:56 CDT(-0500)] <EricDalquist> in 4.0 it requires manual work
[10:41:03 CDT(-0500)] <EricDalquist> in 4.1 we'll be removing the .css files
[10:41:10 CDT(-0500)] <EricDalquist> and having sass be part of the build process
[10:41:19 CDT(-0500)] <EricDalquist> with instructions on how to just do CSS based skinning if you want
[10:41:25 CDT(-0500)] <drewwills> what does the manual work look like? a >mvn plugin command?
[10:41:50 CDT(-0500)] <EricDalquist> yeah
[10:41:54 CDT(-0500)] <drewwills> cool
[10:42:08 CDT(-0500)] <EricDalquist> mvn sass:update-stylesheets
[10:42:16 CDT(-0500)] <EricDalquist> o
[10:42:17 CDT(-0500)] <EricDalquist> mvn sass:watch
[10:42:21 CDT(-0500)] <EricDalquist> http://developer.jasig.org/projects/sass-maven-plugin/1.0.0/plugin-info.html
[10:42:32 CDT(-0500)] <EricDalquist> the plugin is configured in the pom to find our skins correctly
[10:43:20 CDT(-0500)] <drewwills> roger
[10:43:37 CDT(-0500)] <EricDalquist> watch will prompt you to pick a specific skin to watch
[10:43:44 CDT(-0500)] <EricDalquist> as the sass plugin isn't thread safe
[10:43:52 CDT(-0500)] <EricDalquist> so it can only watch one thread at a time
[10:43:57 CDT(-0500)] <EricDalquist> actually not the plugin
[10:44:00 CDT(-0500)] <EricDalquist> sass itself is not thread safe
[12:22:15 CDT(-0500)] <athena> hey EricDalquist - i've been looking at how to re-integrate our stats work
[12:22:38 CDT(-0500)] <athena> the biggest thing i'm noticing right now is that the group mapping object doesn't have a unique id on it
[12:22:49 CDT(-0500)] <athena> just name and service name
[12:22:56 CDT(-0500)] <athena> should we add an id to that?
[12:23:15 CDT(-0500)] <athena> seems like it'd be useful to have the name.service key string if nothing else
[12:24:43 CDT(-0500)] <athena> the AggregatedGroupDao has a method like getGroupMapping(groupId), but i don't see a way to actually get the group ID from the list of group mappings 
[12:46:50 CDT(-0500)] <EricDalquist> athena: just add the getId getter to AggregatedGroupMappingImpl
[12:46:55 CDT(-0500)] <EricDalquist> the id field is there in the db
[12:46:57 CDT(-0500)] <EricDalquist> and the impl
[12:47:01 CDT(-0500)] <EricDalquist> I just never created the getter
[12:47:05 CDT(-0500)] <athena> oh ok
[12:47:08 CDT(-0500)] <athena> awesome
[12:48:04 CDT(-0500)] <athena> hmm.
[12:48:17 CDT(-0500)] <athena> guess we'd need an additional method to be able to look up group mappings based on that
[12:48:22 CDT(-0500)] <EricDalquist> probably
[12:48:33 CDT(-0500)] <EricDalquist> the only code that is there is what was needed for aggregation
[12:48:42 CDT(-0500)] <EricDalquist> so there are probably missing methods for reporting
[12:48:49 CDT(-0500)] <athena> yeah
[12:58:18 CDT(-0500)] <athena> i have no idea how our db stuff works anymore :/
[12:58:26 CDT(-0500)] <EricDalquist> uhoh
[12:58:31 CDT(-0500)] <EricDalquist> whats going on?
[12:58:31 CDT(-0500)] <athena> yeah
[12:58:40 CDT(-0500)] <athena> oh, i just don't even know how to add a simple method
[12:59:12 CDT(-0500)] <EricDalquist> what are you adding?
[12:59:21 CDT(-0500)] <athena> just want to be able to get a group mapping by id
[13:00:36 CDT(-0500)] <EricDalquist> this.getEntityManager().find(AggregatedGroupMappingImpl.class, id)
[13:01:16 CDT(-0500)] <athena> ok
[13:01:29 CDT(-0500)] <athena> so for that sort of thing we're still using relatively vanilla JPA
[13:01:35 CDT(-0500)] <EricDalquist> yup
[13:01:47 CDT(-0500)] <athena> it looks like we're doing a lot with caching, natural ids, criteria queries, etc. though
[13:01:57 CDT(-0500)] <athena> do we have any documentation on which things we're using and when?
[13:02:14 CDT(-0500)] <EricDalquist> so I have this page: https://wiki.jasig.org/display/UPC/JPA+DAO+Guidelines
[13:02:28 CDT(-0500)] <EricDalquist> it doesn't cover how to query for what
[13:02:32 CDT(-0500)] <EricDalquist> I can add that though
[13:02:38 CDT(-0500)] <athena> i think that'd be hlpeful
[13:02:45 CDT(-0500)] <athena> i feel like i've sort of lost track of all this stuff
[13:02:47 CDT(-0500)] <athena> which is my fault
[13:02:54 CDT(-0500)] <EricDalquist> well it is kind of good
[13:02:55 CDT(-0500)] <athena> but then again if i've lost track probably a lot of other people have as well
[13:02:59 CDT(-0500)] <EricDalquist> cause it makes me document it better 
)
[13:03:01 CDT(-0500)] <EricDalquist>
[13:03:04 CDT(-0500)] <athena>
[13:03:13 CDT(-0500)] <athena> at some point it'd be good to figure out some simpler use cases and guidelines for portlet dev
[13:03:23 CDT(-0500)] <athena> we just don't have any examples of JPA portlets
[13:03:30 CDT(-0500)] <athena> our portlets that use custom dbs are pretty old
[13:04:08 CDT(-0500)] <EricDalquist> yeah
[13:35:19 CDT(-0500)] <sjungling> @EricDalquist LDAP continues to be happy through our peak usage for the day
[13:35:31 CDT(-0500)] <EricDalquist> great
[13:35:36 CDT(-0500)] <athena> \ 0 /
[13:35:41 CDT(-0500)] <EricDalquist> with just the switch of the ldap pooling config?
[13:35:46 CDT(-0500)] <sjungling> yep
[13:35:47 CDT(-0500)] <EricDalquist> so you are pooling right now right?
[13:35:53 CDT(-0500)] <sjungling> yes
[13:35:57 CDT(-0500)] <sjungling> using your params
[13:36:01 CDT(-0500)] <EricDalquist> glad to hear it
[13:36:10 CDT(-0500)] <sjungling> although we bumped the maxWait time to 10s per our OpenLDAP vendor
[13:36:14 CDT(-0500)] <sjungling> (from 1s)
[13:36:19 CDT(-0500)] <EricDalquist> ah cool
[13:36:40 CDT(-0500)] <sjungling> i also enabled Tomcat sharedSession, which hadn't been
[13:36:48 CDT(-0500)] <sjungling> not sure how much diff. that would have made
[13:37:20 CDT(-0500)] <sjungling> but our admins report that uPortal is binding and pumping lots of queries through the one connection before unbinding. which sounds efficient
[13:38:17 CDT(-0500)] <EricDalquist> yeah
[13:38:32 CDT(-0500)] <sjungling> so, the last issue we're seeing is w/r/t CAS SingleSignOff events
[13:38:35 CDT(-0500)] <sjungling> https://gist.github.com/11510c8c6ed8b7d5c82a
[13:38:50 CDT(-0500)] <sjungling> and Misagh recommended disabling that globally at the CAS level
[13:38:56 CDT(-0500)] <sjungling> going to aim to do that tonight
[13:39:04 CDT(-0500)] <EricDalquist> can you point the single-sign off to a different URL?
[13:39:17 CDT(-0500)] * EricDalquist has never used CAS
[13:39:20 CDT(-0500)] <sjungling> ah
[13:39:30 CDT(-0500)] <sjungling> not that i'm aware of
[13:39:51 CDT(-0500)] <sjungling> but we've never used the SingleSignOff feature anyway
[13:40:13 CDT(-0500)] <sjungling> log entries in the gist above… was enough to knock out one of our servers from service
[13:40:34 CDT(-0500)] <sjungling> and the when the load balancer tried to re-balance traffic across the remaining two servers, it knocked another one out
[13:44:23 CDT(-0500)] <mmoayyed> Hi Eric; just wanted to confirm: person directory 1.5.1 was just released?
[13:48:27 CDT(-0500)] <EricDalquist> yes
[13:50:46 CDT(-0500)] <mmoayyed> great. CAS is on 1.5.0-RC6. I am going to try and upgrade the dependency for the next release. Any particular changes? release notes?
[13:51:02 CDT(-0500)] <EricDalquist> 1.5.1 was just some logging changes
[13:51:08 CDT(-0500)] <EricDalquist> I can't remember what all was in 1.5.0
[13:54:25 CDT(-0500)] <sjungling> is there a default application session timeout for v4? or is that tied to the container (e.g. Tomcat's) session timeout?
[14:09:29 CDT(-0500)] <EricDalquist> uportal just uses the container's session timeout
[14:14:45 CDT(-0500)] <sjungling> beauty
[14:14:53 CDT(-0500)] <sjungling> what i suspected
[14:16:02 CDT(-0500)] <EricDalquist> the only exception is if you set the org.jasig.portal.PortalSessionManager.unauthenticatedUserSessionTimeout property in portal.properties
[14:16:16 CDT(-0500)] <EricDalquist> if that is set to something other than 0 that overrides the session timeout for guest sessions
[14:16:32 CDT(-0500)] <EricDalquist> like you could set it to 300 so that guest users only have a 5 minute timeout
[14:17:48 CDT(-0500)] <sjungling> kk
[14:17:55 CDT(-0500)] <sjungling> i'm mostly interested in auth'd users
[14:18:16 CDT(-0500)] <sjungling> so if we disable the SingleSignOut message from CAS, sound like they'll lose their Portal session anyway through Tomcats session expiration