uPortal IRC Logs-2012-08-07

Owned by Apereo Infrastructure
Last updated: Aug 07, 2012
14 min read

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

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

[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? (tongue)

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

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

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

[15:53:57 CDT(-0500)] <athena> :0

[15:53:58 CDT(-0500)] <athena> (smile)

[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

[16:28:17 CDT(-0500)] <EricDalquist> so it could be a problem with the stylesheet descriptor that is being resolved when using layout.json

[16:29:51 CDT(-0500)] <athena> gotcha

[16:30:08 CDT(-0500)] <athena> i'll have to take a look at my db

[16:33:57 CDT(-0500)] <athena> hmmm.

[16:34:03 CDT(-0500)] <athena> so can't reproduce the issue right now

[16:34:16 CDT(-0500)] <athena> and also my UP_PORTLET_ENT__STATES table is completely empty