[10:07:08 CDT(-0500)] <athena> morning EricDalquist
[10:07:15 CDT(-0500)] <EricDalquist> good morning
[10:07:28 CDT(-0500)] <EricDalquist> going to try and get 4.0.6 out tomorrow
[10:07:34 CDT(-0500)] <EricDalquist> I'll send a note to the dev list shortly about that
[10:07:37 CDT(-0500)] <athena> oh cool 
[10:07:56 CDT(-0500)] <athena> maybe a good day to see if i can fix a few bugs then
[10:08:12 CDT(-0500)] <athena> i tracked down some misbehavior yesterday, though i think i need your insight into what's actually happening
[10:08:39 CDT(-0500)] <athena> portlet admin portlet is having issues with portlets that use config mode
[10:08:59 CDT(-0500)] <EricDalquist> oh right
[10:09:03 CDT(-0500)] <athena> it looks like what happens is that when the admin portlet exits config mode, it refreshes the portlet definition
[10:09:11 CDT(-0500)] <athena> which makes sense, since config mode likely changed some preferences
[10:09:20 CDT(-0500)] <athena> problem is, it gets an outdated version of those preferences
[10:09:25 CDT(-0500)] <athena> and then if you hit save re-saves them
[10:09:30 CDT(-0500)] <athena> so not sure if this is a caching issue or what
[10:09:36 CDT(-0500)] <EricDalquist> oh ... that is interesting
[10:09:47 CDT(-0500)] <athena> though i did notice that the publishing service is using the portlet definition dao, rather than the portlet definition registry
[10:09:50 CDT(-0500)] <EricDalquist> so first step would be to see if the prefs are ever even saved to the db
[10:10:03 CDT(-0500)] <athena> pretty sure they are
[10:10:20 CDT(-0500)] <athena> since config mode works sometimes
[10:10:41 CDT(-0500)] <athena> suspect it works when you don't hit save in the portlet admin portlet itself
[10:10:57 CDT(-0500)] <EricDalquist> right
[10:11:00 CDT(-0500)] <athena> hard to tell by just looking at the db though, since it's all clobs
[10:11:05 CDT(-0500)] <EricDalquist> yeah
[10:11:09 CDT(-0500)] <EricDalquist> you could turn on sql logging
[10:11:15 CDT(-0500)] <EricDalquist> but that's a bit verbose
[10:12:06 CDT(-0500)] <EricDalquist> or if you use hsql locally
[10:12:14 CDT(-0500)] <athena> tried switching the publishing service over to use the registry, which i think is what we want
[10:12:15 CDT(-0500)] <EricDalquist> you can tail ./data/uPortal.log
[10:12:19 CDT(-0500)] <athena> though that resulted in some other errors
[10:13:08 CDT(-0500)] <athena> i'll do a bit more poking around this morning and make sure the prefs are getting saves
[10:13:11 CDT(-0500)] <EricDalquist> ok
[10:13:14 CDT(-0500)] <athena> if they are, i guess it's probably caching-related
[10:13:24 CDT(-0500)] <EricDalquist> yeah
[10:13:26 CDT(-0500)] <EricDalquist> which is weird
[10:13:34 CDT(-0500)] <EricDalquist> since the only thing that should be caching that data is hibernate
[10:13:43 CDT(-0500)] <EricDalquist> and those caches should always be consistent
[10:13:49 CDT(-0500)] <athena> yeah
[10:13:58 CDT(-0500)] <athena> the other thing worth mentioning before 4.0.6 is that we're still getting reports of all the portlets getting rendered minimized in the desktop view
[10:14:26 CDT(-0500)] <athena> which i thought we'd fixed, but still getting reports of that as of 4.0.5
[10:14:42 CDT(-0500)] <EricDalquist> huh
[10:14:44 CDT(-0500)] <EricDalquist> ok
[10:14:57 CDT(-0500)] <EricDalquist> I'll read through jira and see if there is anything reported there that is reproducable
[10:15:31 CDT(-0500)] <athena> sounds good
[10:15:45 CDT(-0500)] <athena> don't know if anyone's filed a jira on that or not - have heard a couple anectodal reports in the last week or so
[10:15:58 CDT(-0500)] <EricDalquist> any luck with that login perf case?
[10:16:09 CDT(-0500)] <athena> going to try reproducing that as well - suspect the best thing to try first is using mobile and desktop at the same time
[10:16:19 CDT(-0500)] <athena> unclear
[10:16:23 CDT(-0500)] <EricDalquist> yeah
[10:16:34 CDT(-0500)] <athena> got some thread dumps yesterday
[10:16:41 CDT(-0500)] <athena> tons of threads waiting on monitors
[10:16:53 CDT(-0500)] <athena> all stuck in GroupService
[10:17:05 CDT(-0500)] <athena> noticed that you changed the synchronization logic there and suggested trying applying that patch
[10:17:19 CDT(-0500)] <EricDalquist> oh huh
[10:17:20 CDT(-0500)] <EricDalquist> yeah
[10:17:23 CDT(-0500)] <athena> dunno if that could be triggered by the use of template users, but that does seem possible
[10:17:30 CDT(-0500)] <EricDalquist> there is a lot of really aggressive sync in there
[10:18:44 CDT(-0500)] <athena> yeah
[10:18:58 CDT(-0500)] <athena> have encouraged both applying that patch and dropping the custom template users
[10:21:28 CDT(-0500)] <athena> restarting, back in a few
[10:21:34 CDT(-0500)] <EricDalquist> k
[10:55:44 CDT(-0500)] <athena> ok EricDalquist
[10:55:49 CDT(-0500)] <athena> database is indeed being updated
[10:55:56 CDT(-0500)] <EricDalquist> ok
[10:55:58 CDT(-0500)] <EricDalquist> that's good
[10:56:10 CDT(-0500)] <EricDalquist> so now to figure out why the portlet admin flow isn't getting the updated portlet definition
[10:56:12 CDT(-0500)] <athena> yeah
[10:56:32 CDT(-0500)] <athena> have confirmed it does get a new portlet form, but that the portlet definition that that logic gets isn't updated
[10:56:49 CDT(-0500)] <EricDalquist> the other thing to check is if there if there is a flow like: config updates prefs, admin overwrites with old prefs, admin reloads portlet def
[10:56:50 CDT(-0500)] <athena> that'd be at PortletAdministrationHelper line 187
[10:57:12 CDT(-0500)] <EricDalquist> ah!
[10:57:17 CDT(-0500)] <EricDalquist> @RequestCache
[10:57:24 CDT(-0500)] <EricDalquist> so that is a bug
[10:57:25 CDT(-0500)] <athena> where is that?
[10:57:38 CDT(-0500)] <EricDalquist> line 109 of PortletDefinitionRegistryImpl
[10:57:42 CDT(-0500)] <EricDalquist> just delete that line for now
[10:57:42 CDT(-0500)] <athena> ah
[10:57:44 CDT(-0500)] <athena> ok
[10:57:45 CDT(-0500)] <EricDalquist> as a bug
[10:58:05 CDT(-0500)] <athena> ok
[10:58:08 CDT(-0500)] <athena> what's that do?
[10:58:21 CDT(-0500)] <EricDalquist> it caches the result of that method for the duration of the current request
[10:58:32 CDT(-0500)] <EricDalquist> it should be a big deal for performance
[10:58:36 CDT(-0500)] <EricDalquist> it was a minor tweak
[10:58:48 CDT(-0500)] <EricDalquist> but it appearntly needs more thought before being applied to some places
[11:02:25 CDT(-0500)] <athena> ah, gotcha
[11:10:29 CDT(-0500)] <athena> so something else i'd like to do is to upgrade jquery and jquery mobile
[11:10:34 CDT(-0500)] <EricDalquist> ok
[11:10:37 CDT(-0500)] <athena> and also include backbone.js and underscore.js
[11:10:43 CDT(-0500)] <EricDalquist> is the upgrade non breaking for existing skins?
[11:10:50 CDT(-0500)] <athena> yeah, seems like
[11:10:55 CDT(-0500)] <EricDalquist> ok
[11:11:49 CDT(-0500)] <athena> it seems like backbone at this point has some nice rendering capabilities
[11:11:56 CDT(-0500)] <athena> getting a lot more usage at unicon
[11:12:02 CDT(-0500)] <EricDalquist> ok
[11:12:09 CDT(-0500)] <EricDalquist> I'm fine with that if the changes are low risk
[11:12:11 CDT(-0500)] <athena> i've create a couple test implementations for our portlet - think it's a bit more intuitive for templating
[11:12:13 CDT(-0500)] <athena> i think so
[11:12:16 CDT(-0500)] <EricDalquist> its been clsoe to 4 months sinve 4.0.5
[11:12:21 CDT(-0500)] <athena> oh wow, yeah
[11:12:23 CDT(-0500)] <EricDalquist> so I really want to get it out tomorrow
[11:12:25 CDT(-0500)] <athena> ok
[11:12:30 CDT(-0500)] <EricDalquist> since the events stuff is finally done
[11:12:48 CDT(-0500)] <athena> those libs are already in the resource server
[11:13:04 CDT(-0500)] <athena> so if we're ok with making those changes, i can cut a release of that and add the libs to the mobile and desktop import lists
[11:13:14 CDT(-0500)] <EricDalquist> ok
[11:13:20 CDT(-0500)] <EricDalquist> if you can do that today that would be good
[11:13:21 CDT(-0500)] <athena> it does add more js, but the libraries aren't huge compared to things like jquery ui
[11:13:25 CDT(-0500)] <athena> yeah that should be ok
[11:13:30 CDT(-0500)] <athena> will fix this portlet admin bug first though
[11:13:35 CDT(-0500)] <EricDalquist> great
[11:13:48 CDT(-0500)] <EricDalquist> I'm working on that @Transactional(readOnly) stuff for postgres
[11:13:54 CDT(-0500)] <EricDalquist> we can't get a real fix in until 4.1
[11:14:00 CDT(-0500)] <EricDalquist> as it requires a schema change
[11:14:45 CDT(-0500)] <athena> ugh
[11:14:53 CDT(-0500)] <athena> how does that affect postgres adopters?
[11:15:01 CDT(-0500)] <EricDalquist> but I think I can code it up so that readOnly transactional annotation is only applied for postgres
[11:15:18 CDT(-0500)] <EricDalquist> well ... right now I believe it works on postgres
[11:15:49 CDT(-0500)] <EricDalquist> but people on other DBs have to comment out those read-only TX annotations
[11:16:03 CDT(-0500)] <EricDalquist> for 4.1 I'll work with the hibernate folks to get to a good solution
[11:16:20 CDT(-0500)] <athena> ah
[11:16:31 CDT(-0500)] <athena> argh i can't find the ticket for that portlet admin config issue
[11:16:44 CDT(-0500)] <EricDalquist> eh
[11:16:49 CDT(-0500)] <EricDalquist> dupes are easy to fix later
[11:17:23 CDT(-0500)] <athena> fair enough
[11:33:12 CDT(-0500)] <athena> ok, so remind me of the flags we need for mvn:release these days?
[11:33:23 CDT(-0500)] <athena> do we still need to specify stuff or is it all auto-configured now?
[11:33:26 CDT(-0500)] <EricDalquist> uh
[11:33:29 CDT(-0500)] <EricDalquist> for uPortal nothing
[11:33:36 CDT(-0500)] <EricDalquist> I can't remember what other project's I've fixed up
[11:33:40 CDT(-0500)] <athena> lol
[11:33:44 CDT(-0500)] <EricDalquist> you could compare the release plugin config in the uportal pom
[11:33:48 CDT(-0500)] <EricDalquist> to the project you are working in
[11:33:48 CDT(-0500)] <athena> maybe i should include them just in case then?
[11:33:57 CDT(-0500)] <athena> resource server, in this case
[11:33:58 CDT(-0500)] <EricDalquist> and get it so it is all automatic
[11:34:02 CDT(-0500)] <athena> sure
[11:34:06 CDT(-0500)] <EricDalquist> its easy enough to tweak the pom
[11:34:14 CDT(-0500)] <athena> so this needs to be in the project, rather than the parent?
[11:40:37 CDT(-0500)] <EricDalquist> yes
[11:40:43 CDT(-0500)] <EricDalquist> it is mostly project specific
[11:40:47 CDT(-0500)] <EricDalquist> like if it is multi-module]
[11:40:53 CDT(-0500)] <EricDalquist> what version controll it is using
[11:40:59 CDT(-0500)] <EricDalquist> and tag naming
[11:42:31 CDT(-0500)] <athena> yeah that makes sense
[11:43:44 CDT(-0500)] <drewwills> morning folks
[11:44:06 CDT(-0500)] <drewwills> I wanted to bring up something i noticed yesterday, just as an FYI...
[11:44:28 CDT(-0500)] <drewwills> the cache TTL for the ...IEntity cahce defaults to 6 hours
[11:45:00 CDT(-0500)] <drewwills> for SSP, we're setting some user attrs in the User Manager that place users in PAGS groups
[11:45:35 CDT(-0500)] <drewwills> and the long TTL value basiclly meant I effectively had to clear the cache in order to see the changes
[11:45:46 CDT(-0500)] <drewwills> i scaled it back to 5 min
[11:46:00 CDT(-0500)] <drewwills> do we really need such a long TTL as the default?
[11:46:04 CDT(-0500)] <athena> we've run into that w/ the conference app as well
[11:46:15 CDT(-0500)] <drewwills> shouldn't 5 min be plenty?
[11:46:30 CDT(-0500)] <athena> in that case one thing we've done is had code that manually reset the cache whenever a user updated their attributes
[11:46:42 CDT(-0500)] <athena> so that the long cache could be in effect when possible
[11:46:43 CDT(-0500)] <EricDalquist> it is a VERY high traffic cache
[11:46:48 CDT(-0500)] <EricDalquist> considering on one of our servers
[11:46:52 CDT(-0500)] <EricDalquist> that has been up for 5 hours
[11:46:54 CDT(-0500)] <drewwills> oh... and I added a msg: "Note:Â some changes may require a few minutes to take effect."
[11:46:59 CDT(-0500)] <EricDalquist> (1191907hits, 5620misses
[11:47:09 CDT(-0500)] <EricDalquist> note that in 4.0.6 we are including jGroups out of the box
[11:47:25 CDT(-0500)] <EricDalquist> and an updated ehcache.xml that uses invalidation messages to resolve this
[11:47:40 CDT(-0500)] <drewwills> well i could selectively .remove() the changed object, but it would only affect the current server node
[11:47:43 CDT(-0500)] <EricDalquist> so if you setup jGroups correctly when one server updates the cache
[11:47:53 CDT(-0500)] <EricDalquist> it will remove that entry from the cache on all other servers
[11:48:03 CDT(-0500)] <drewwills> ah roger
[11:48:18 CDT(-0500)] <EricDalquist> but yeah ... a 5 minute TTL would have a performance impact
[11:49:17 CDT(-0500)] <drewwills> so is jGroups another GaP flavor? or something else?
[11:49:18 CDT(-0500)] <EricDalquist> so in 5 hours we have seen 66 hits/second on that cache
[11:49:34 CDT(-0500)] <EricDalquist> jGroups is a multicast based clustering tool
[11:49:41 CDT(-0500)] <EricDalquist> and ehcache has a jgroups plugin
[11:49:45 CDT(-0500)] <drewwills> ah ok
[11:49:47 CDT(-0500)] <EricDalquist> for clustered caching
[11:49:51 CDT(-0500)] <drewwills> will it be on by default
[11:49:52 CDT(-0500)] <drewwills> ?
[11:49:53 CDT(-0500)] <EricDalquist> in this case we are using it in invalidation mode
[11:49:55 CDT(-0500)] <EricDalquist> yes
[11:49:59 CDT(-0500)] <drewwills> very nice
[11:50:04 CDT(-0500)] <EricDalquist> but depending on local network topology work will be required
[11:50:12 CDT(-0500)] <EricDalquist> it "just works" on a single box
[11:50:16 CDT(-0500)] <EricDalquist> like if uPortal is running
[11:50:23 CDT(-0500)] <EricDalquist> and you run data-import
[11:50:23 CDT(-0500)] <drewwills> we could create a JIRA for the UserAccountHelper to invalidate some cache objects when it makes changes
[11:50:33 CDT(-0500)] <EricDalquist> the caches on the running instance are appropriatly cleared
[11:50:39 CDT(-0500)] <EricDalquist> it is automatic
[11:50:49 CDT(-0500)] <EricDalquist> put, remove, and removeall operations on an Ehcache are propegated
[11:51:01 CDT(-0500)] <EricDalquist> all via invalidation
[11:51:15 CDT(-0500)] <EricDalquist> so if on server A some code does cache.put("foo", ...)
[11:51:28 CDT(-0500)] <EricDalquist> a message is sent out to all severs that says "remove foo from cache"
[11:51:47 CDT(-0500)] <drewwills> cool
[11:51:52 CDT(-0500)] <EricDalquist> https://wiki.jasig.org/display/UPM40/Clustering
[11:54:08 CDT(-0500)] <EricDalquist> but essentially any time any group or permission check is made
[11:54:12 CDT(-0500)] <EricDalquist> the IEntity cache is hit
[12:00:13 CDT(-0500)] <drewwills> https://issues.jasig.org/browse/UP-3535
[12:00:56 CDT(-0500)] <EricDalquist> drewwills: which method in user account helper affects the change?
[12:01:08 CDT(-0500)] <drewwills> i think it's called update()
[12:01:10 CDT(-0500)] <drewwills> 1 sec
[12:01:12 CDT(-0500)] <EricDalquist> if whatever it is results in a .put in the IEntity cache
[12:01:15 CDT(-0500)] <EricDalquist> then you're all set
[12:02:10 CDT(-0500)] <drewwills> ok maybe what we need is a put(), not an invalidate, but i don't think it does it
[12:02:27 CDT(-0500)] <EricDalquist> so looking at updateAccount it appears to only modify the ILocalAccountPerson
[12:02:32 CDT(-0500)] <EricDalquist> which is a JPA managed object
[12:02:39 CDT(-0500)] <EricDalquist> so the cache invalidation stuff there should be automatic
[12:02:50 CDT(-0500)] <drewwills> i need to look deeper... i think it may be changing (e.g.) an IPerson, but the cached object is of type IGroupMamber... orsomething like that
[12:03:02 CDT(-0500)] <athena> i think our code flushed entity, group, and permission caches
[12:03:38 CDT(-0500)] <drewwills> "our code" from the mobile app?
[12:03:48 CDT(-0500)] <EricDalquist> ah ok ... so this is an indirect thing ...
[12:03:58 CDT(-0500)] <EricDalquist> you're changing the attributes in a ILocalAccountPerson
[12:03:59 CDT(-0500)] <athena> from the one-off conference modifications
[12:04:01 CDT(-0500)] <EricDalquist> which will get replicated
[12:04:06 CDT(-0500)] <EricDalquist> but PAGs doesn'
[12:04:10 CDT(-0500)] <athena> yep
[12:04:12 CDT(-0500)] <EricDalquist> t pick that up
[12:04:20 CDT(-0500)] <drewwills> exactly
[12:04:27 CDT(-0500)] <EricDalquist> uhg
[12:04:28 CDT(-0500)] <EricDalquist> that isn'
[12:04:28 CDT(-0500)] <drewwills> well it does... in 6 hrs
[12:04:31 CDT(-0500)] <athena> and i think the permission cache needs to be manually reset as well
[12:04:36 CDT(-0500)] <EricDalquist> isn't an easy thing to fix well
[12:04:56 CDT(-0500)] <EricDalquist> I could see dropping the IEntity TTL to ~30 minutes
[12:05:01 CDT(-0500)] <EricDalquist> or whatever your standard session length is
[12:05:17 CDT(-0500)] <athena> so are we better off with a lower cache or manual cache resets?
[12:05:28 CDT(-0500)] <drewwills> good question
[12:05:28 CDT(-0500)] <athena> seems like it depends in part on how often the user attributes are changed
[12:05:35 CDT(-0500)] <EricDalquist> brb with an answer
[12:05:41 CDT(-0500)] <drewwills> and the traffic on the system
[12:09:11 CDT(-0500)] <athena> bbiab
[12:09:56 CDT(-0500)] <EricDalquist> ok drewwills I think I have an answer for you
[12:10:08 CDT(-0500)] <EricDalquist> are you working off of some recent version of master?
[12:13:20 CDT(-0500)] <EricDalquist> drewwills: let me know when you're back
[12:13:24 CDT(-0500)] <EricDalquist> and we can talk about a solution
[12:14:10 CDT(-0500)] <drewwills> i'm back, and yes it's a recent version of master
[12:14:16 CDT(-0500)] <drewwills> *based on
[12:14:19 CDT(-0500)] <EricDalquist> ok
[12:14:37 CDT(-0500)] <EricDalquist> so I added a feature that allows us to "tag" cache entries
[12:15:06 CDT(-0500)] <drewwills> just now? 
[12:15:11 CDT(-0500)] <EricDalquist> to get it working you need to go into ehcache.xml and add the following in the <cache> element for caches that might have tagged ketys
[12:15:14 CDT(-0500)] <EricDalquist> no a few months ago
[12:15:17 CDT(-0500)] <EricDalquist> just forgot about it
[12:15:19 CDT(-0500)] <EricDalquist> <cacheEventListenerFactory class="org.jasig.portal.utils.cache.SpringCacheEventListenerFactory" properties="beanName=tagTrackingCacheEventListener" listenFor="local" />
[12:15:59 CDT(-0500)] <EricDalquist> then you need to find where in GaP the IEntity cache is used
[12:16:22 CDT(-0500)] <EricDalquist> and rewrite how the key is generated to use the org.jasig.portal.utils.cache.CacheKey class
[12:16:44 CDT(-0500)] <drewwills> GaP is one of the more... exciting... areas to sort out at this point in history
[12:16:51 CDT(-0500)] <EricDalquist> yes
[12:16:52 CDT(-0500)] <EricDalquist> it is
[12:17:03 CDT(-0500)] <EricDalquist> you can see in org.jasig.portal.utils.cache.PersonDirectoryCacheKeyGenerator how CacheKey is used
[12:17:17 CDT(-0500)] <EricDalquist> the important line looks like: cacheKeyBuilder.addTag(UsernameTaggedCacheEntryPurger.createCacheEntryTag((String) usernameValue));
[12:17:18 CDT(-0500)] <drewwills> gotcha
[12:17:31 CDT(-0500)] <EricDalquist> that "tags" the cache key with the username
[12:18:04 CDT(-0500)] <drewwills> and thereafter invalidating the user has a cascading effect?
[12:18:07 CDT(-0500)] <EricDalquist> you could use the username or any other tag you want to come up with
[12:18:08 CDT(-0500)] <EricDalquist> sort of
[12:18:25 CDT(-0500)] <EricDalquist> the way it is setup now UsernameTaggedCacheEntryPurger listens for LoginEvent and LogoutEvent
[12:18:37 CDT(-0500)] <EricDalquist> and when that happens it calls TaggedCacheEntryPurger.purgeCacheEntries
[12:18:46 CDT(-0500)] <EricDalquist> with the username tag
[12:18:56 CDT(-0500)] <EricDalquist> and that removes all cache entries across all caches tagged with that username
[12:19:15 CDT(-0500)] <EricDalquist> so you would update that account admin helper
[12:19:27 CDT(-0500)] <EricDalquist> to make that same call
[12:19:43 CDT(-0500)] <drewwills> gotcha... so you still have to make a call, but it's "purge anything with xx tag" not "purge this thing in permissions, now purge this thing in groups, etc"
[12:19:52 CDT(-0500)] <EricDalquist> right
[12:20:01 CDT(-0500)] <EricDalquist> and you don't care about having to recreate all the various keys
[12:20:09 CDT(-0500)] <EricDalquist> since they probably contain more than just the username
[12:20:39 CDT(-0500)] <drewwills> cool
[12:20:48 CDT(-0500)] <EricDalquist> that was a pretty rough summary
[12:20:54 CDT(-0500)] <EricDalquist> so ping me if you run into weirdness with it
[12:20:59 CDT(-0500)] <drewwills> that's ok, there are examples
[12:21:07 CDT(-0500)] <EricDalquist> the hardest part will probably be refactoring GaP to generate tagged keys
[13:21:54 CDT(-0500)] <athena> heh we just got another support request for this issue
[13:22:04 CDT(-0500)] <athena> not sure why people seem to be running up against that more lately
[13:23:01 CDT(-0500)] <EricDalquist> for the entity cache issue?
[13:23:12 CDT(-0500)] <athena> ywH
[13:23:15 CDT(-0500)] <athena> er, yes
[13:24:30 CDT(-0500)] <drewwills> wow
[13:24:50 CDT(-0500)] <athena> we had another case for that a couple weeks ago
[13:26:37 CDT(-0500)] <drewwills> i guess it's getting around to using features that are newer and were not commonly used in uPortals of yore
[13:26:51 CDT(-0500)] <EricDalquist> yeah
[13:26:58 CDT(-0500)] <EricDalquist> we're getting a lot more dynamic usage
[13:27:11 CDT(-0500)] <EricDalquist> and there are parts (GaP) that don't have good data consistency
[13:28:27 CDT(-0500)] <drewwills> i hope that we can pick up new talent & energy from things like uMobile/SSP capable of taking on some of those tasks
[13:28:38 CDT(-0500)] <EricDalquist> yeah
[13:32:07 CDT(-0500)] <drewwills> gogo OU – first uMobile
[13:32:34 CDT(-0500)] <athena> yes
[13:32:55 CDT(-0500)] <drewwills> weren't they first on uP4 as well? do I remember correctly?
[13:43:28 CDT(-0500)] <athena> not sure but sounds plausible
[13:43:31 CDT(-0500)] <athena> certainly among the first
[13:43:41 CDT(-0500)] <athena> so far they've published ios but not android
[14:43:09 CDT(-0500)] <athena> EricDalquist: so it turns out actually we need jquery 1.6.4 instead of 1.7
[14:43:22 CDT(-0500)] <EricDalquist> ?
[14:43:26 CDT(-0500)] <athena> already cut the release of the resource server, but haven't released the artifact
[14:43:30 CDT(-0500)] <EricDalquist> what does 4.0 ship with now?
[14:43:32 CDT(-0500)] <athena> or pushed the git changes to our repo
[14:43:35 CDT(-0500)] <athena> 1.6.1
[14:43:45 CDT(-0500)] <athena> so thinking it makes more sense to re-cut the release?
[14:43:54 CDT(-0500)] <EricDalquist> sure ...
[14:44:05 CDT(-0500)] <EricDalquist> since you haven't pushed the git changes anywhere
[14:44:23 CDT(-0500)] <athena> so i just need to figure out how to drop those local commits?
[14:44:37 CDT(-0500)] <EricDalquist> you can do:
[14:44:37 CDT(-0500)] <EricDalquist> git tag delete tagname
[14:44:38 CDT(-0500)] <EricDalquist> git reset --hard COMMIT_ID_RIGHT_BEFORE_RELEASE
[14:44:55 CDT(-0500)] <EricDalquist> gitk& will give you a nice GUI browser of the git history
[14:45:04 CDT(-0500)] <athena> nice
[14:45:08 CDT(-0500)] <EricDalquist> so you can get the commit id immediately before the release work
[14:45:20 CDT(-0500)] <athena> makes sense
[15:36:21 CDT(-0500)] <EricDalquist> fyi I just broke master
[15:36:24 CDT(-0500)] <EricDalquist> trying to fix it now ...
[15:52:24 CDT(-0500)] <EricDalquist> ok fixed
[15:52:41 CDT(-0500)] <EricDalquist> athena: do you happen to have master configured against postgres in an easy to test configuration?
[15:53:47 CDT(-0500)] <athena> no
[15:53:54 CDT(-0500)] <EricDalquist> ok I'll see if I can get one setup
[15:53:57 CDT(-0500)] <athena> :0
[15:53:58 CDT(-0500)] <athena>
[15:54:13 CDT(-0500)] <athena> i haven't used my postgresdb in ages
[16:21:44 CDT(-0500)] <athena> ok EricDalquist - looks like tacoma just submitted a good description of the minimization issue
[16:21:44 CDT(-0500)] <athena> https://issues.jasig.org/browse/UP-3537
[16:21:50 CDT(-0500)] <athena> such that we could actually reproduce it
[16:22:58 CDT(-0500)] <EricDalquist> oh great
[16:23:04 CDT(-0500)] <EricDalquist> ok that gives me an idea of where to look
[16:23:10 CDT(-0500)] <athena> terrific
[16:23:55 CDT(-0500)] <EricDalquist> there is code that minimizes all portlets
[16:24:03 CDT(-0500)] <EricDalquist> but it should be associated with a different profile
[16:24:38 CDT(-0500)] <athena> yeah
[16:25:40 CDT(-0500)] <athena> hmm.
[16:25:49 CDT(-0500)] <athena> unable to duplicate that via using the cache manager portlet
[16:25:53 CDT(-0500)] <athena> suppose could try actually waiting instead
[16:26:01 CDT(-0500)] <athena> though seems like the cache manager should do it
[16:26:06 CDT(-0500)] <EricDalquist> ?
[16:26:16 CDT(-0500)] <EricDalquist> oh right
[16:27:11 CDT(-0500)] <athena> is that table he referenced normally associated w/ a profile?
[16:27:45 CDT(-0500)] <EricDalquist> it is associated with a StylesheetDescriptor