uPortal IRC Logs-2012-08-29

Owned by Apereo Infrastructure
Last updated: Aug 29, 2012
6 min read

[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 (smile)

[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 (sad))

[13:03:01 CDT(-0500)] <EricDalquist> (smile)

[13:03:04 CDT(-0500)] <athena> (smile)

[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

[14:18:53 CDT(-0500)] <EricDalquist> yeah