[13:07:25 CDT(-0500)] <sjungling> hey guys, since upgrading to 4.0.5 yesterday, our LDAP server has been having stability issues. our networking guys see that each application instance is creating 11+ connections to our LDAP server throughout the day. we have connection pooling enable for LDAP, but i was wondering if anyone else has had issues w/ LDAP on 4.0.x
[13:07:51 CDT(-0500)] <EricDalquist> what did you upgrade from
[13:08:02 CDT(-0500)] <EricDalquist> and no, we haven't but the ldap code hasn't really changed since 3.0
[13:08:13 CDT(-0500)] <sjungling> we came from 2.6
[13:08:47 CDT(-0500)] <EricDalquist> so my first guess would be persondirectory caching
[13:08:59 CDT(-0500)] <sjungling> yeah… we're not using it as far as I can tell
[13:09:02 CDT(-0500)] <EricDalquist> it was just pointed out that the default person dir config doesn't have any caching enabled
[13:09:03 CDT(-0500)] <sjungling> (caching that is)
[13:09:07 CDT(-0500)] <athena> yeah
[13:09:09 CDT(-0500)] <EricDalquist> and that would cause a lot of load on the attribute sources
[13:09:17 CDT(-0500)] <athena> i think we need to fix the default configurations
[13:09:20 CDT(-0500)] <athena> and get that documented
[13:09:29 CDT(-0500)] <athena> i bet a bunch of people are running w/o caching at this point
[13:09:41 CDT(-0500)] <EricDalquist> yeah
[13:09:45 CDT(-0500)] <EricDalquist> so here is a big example: https://wiki.jasig.org/download/attachments/27525146/personDirectoryContext.xml?version=1&modificationDate=1256668239118
[13:10:14 CDT(-0500)] <EricDalquist> and I created https://issues.jasig.org/browse/UP-3555 as a reminder
[13:10:26 CDT(-0500)] <EricDalquist> maybe I can get to that this week
[13:10:33 CDT(-0500)] <EricDalquist> I will for sure before 4.0.7
[13:10:43 CDT(-0500)] <EricDalquist> and we can make an announcement about it too
[13:11:52 CDT(-0500)] <sjungling> sweet. i'll start converting over my config to use caching
[13:12:06 CDT(-0500)] <EricDalquist> you'll need to add the corresponding caches in ehcache.xml
[13:12:17 CDT(-0500)] <EricDalquist> in general even short timeouts are valuable
[13:12:24 CDT(-0500)] <EricDalquist> like 5 min
[13:12:36 CDT(-0500)] <EricDalquist> time out == TTL
[13:13:19 CDT(-0500)] <sjungling> there an example of how to mod ehcache.xml?
[13:13:50 CDT(-0500)] <EricDalquist> it is pretty straight forward, just copy one of the <cache> elements and change the name/size/ttl to what you need
[13:14:30 CDT(-0500)] <sjungling> gotcha
[13:47:06 CDT(-0500)] <sjungling> took a stab at implementing caching in personDirectoryContext.xml (https://gist.github.com/c13e7049cb3685b17abb) but am seeing the error below when deploying.
[13:47:06 CDT(-0500)] <sjungling> "[org.jasig.portal.utils.cache.PersonDirectoryCacheKeyGenerator]: Bean property 'useAllAttributes' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?"
[13:55:32 CDT(-0500)] <EricDalquist> just remove that
[13:55:38 CDT(-0500)] <EricDalquist> that <property>
[13:55:44 CDT(-0500)] <EricDalquist> I think the example needs updating
[13:56:51 CDT(-0500)] <sjungling> kk. so the userAttributeCacheKeyGenerator will just have ignoreEmptyAttributes as the only prop?
[13:57:30 CDT(-0500)] <EricDalquist> yes
[13:57:31 CDT(-0500)] <EricDalquist> <bean id="userAttributeCacheKeyGenerator" class="org.jasig.portal.utils.cache.PersonDirectoryCacheKeyGenerator">
[13:57:31 CDT(-0500)] <EricDalquist> <property name="ignoreEmptyAttributes" value="true" />
[13:57:31 CDT(-0500)] <EricDalquist> </bean>
[14:02:25 CDT(-0500)] <sjungling> k. resolved that error and uncovered another error => https://gist.github.com/e17f60bc8fa75d7d6b61
[14:09:58 CDT(-0500)] <sjungling> hrm. looks like there was a missing cache from ehcache.xml, lets see if that makes a difference
[14:21:37 CDT(-0500)] <sjungling> blerg. still the same thing
[14:47:03 CDT(-0500)] <EricDalquist> hrm
[14:47:10 CDT(-0500)] <EricDalquist> I'm back sjungling I'll take a quick peek
[14:48:07 CDT(-0500)] <sjungling> ty. just updated https://gist.github.com/c13e7049cb3685b17abb
[14:48:22 CDT(-0500)] <sjungling> (to reflect the removed property from userAttributeCacheKeyGenerator)
[14:48:35 CDT(-0500)] <EricDalquist> ah ok
[14:48:47 CDT(-0500)] <EricDalquist> so look at line 202
[14:48:52 CDT(-0500)] <EricDalquist> <property name="cacheFactory" ref="cacheFactory"/>
[14:49:02 CDT(-0500)] <EricDalquist> then look at line 237
[14:49:13 CDT(-0500)] <EricDalquist> you have a few MapCacheFactoryBeans that are missing the cacheFactory property
[14:50:09 CDT(-0500)] <sjungling> missing lines added
[14:58:52 CDT(-0500)] <drewwills> hey folks... does anyone know of schools besides OHIO that are actively using the Emergency Alert portlet in prod?
[15:21:44 CDT(-0500)] <sjungling> @EricDalquist ok, after a few attempts (needed to comment out some unused beans) my personDirectoryContext wound up looking like this: https://gist.github.com/c13e7049cb3685b17abb
[15:21:57 CDT(-0500)] <sjungling> which now throws a different error https://gist.github.com/ecd0816cf8ab819ec075
[15:22:35 CDT(-0500)] <EricDalquist> hrm
[15:22:58 CDT(-0500)] <sjungling> just tacked on ehcache.xml to https://gist.github.com/c13e7049cb3685b17abb
[15:23:38 CDT(-0500)] <EricDalquist> something weird is going on ...
[15:24:17 CDT(-0500)] <EricDalquist> I just realized that in 4.0.5 it appears that MapCAcheFactoryBean has:
[15:24:17 CDT(-0500)] <EricDalquist> @Autowired
[15:24:17 CDT(-0500)] <EricDalquist> public void setCacheFactory(CacheFactory cacheFactory) {
[15:24:25 CDT(-0500)] <EricDalquist> so the cache factory should be getting created correctly
[15:26:41 CDT(-0500)] <EricDalquist> just to satiate my curiosity ... try going to uportal-war/src/main/resources/properties/contexts/channelContainerContext.xml
[15:26:46 CDT(-0500)] <sjungling> i upgraded to 4.0.6 this AM
[15:26:51 CDT(-0500)] <EricDalquist> oh
[15:26:52 CDT(-0500)] <EricDalquist> ok
[15:26:57 CDT(-0500)] <EricDalquist> so this is all 4.0.6
[15:27:05 CDT(-0500)] <sjungling> per the other issue w/ Oracle & Event Logging
[15:27:08 CDT(-0500)] <sjungling> correct
[15:27:12 CDT(-0500)] <EricDalquist> ok
[15:27:16 CDT(-0500)] <sjungling> sorry, should have stated that earlier
[15:27:41 CDT(-0500)] <EricDalquist> no problem
[15:28:42 CDT(-0500)] <sjungling> here's channelContainer for ref https://gist.github.com/c13e7049cb3685b17abb#file_channel_container_context.xml
[15:29:12 CDT(-0500)] <EricDalquist> yeah
[15:29:13 CDT(-0500)] <EricDalquist> that is right
[15:29:27 CDT(-0500)] <EricDalquist> and honestly you shouldn't have needed the other cacheManager properties either
[15:29:37 CDT(-0500)] <EricDalquist> but for some reason CacheManager isn't getting injected
[15:29:41 CDT(-0500)] <EricDalquist> which is ... weirdc
[15:31:52 CDT(-0500)] <sjungling> would more info from uPortal.log help?
[15:31:53 CDT(-0500)] <EricDalquist> did youhave any issues merging with 4.0.6?
[15:31:56 CDT(-0500)] <EricDalquist> it might
[15:32:15 CDT(-0500)] <EricDalquist> this was starting correctly before you made your personDirectoryContext.xml mods?
[15:32:50 CDT(-0500)] <sjungling> correct
[15:32:55 CDT(-0500)] <sjungling> i have 4.0.6 running on a dev server
[15:33:12 CDT(-0500)] <sjungling> but it was after attempting to move personDirs over to caching that i started seeing these errors
[15:33:18 CDT(-0500)] <sjungling> 4.0.6 merged automatically
[15:33:22 CDT(-0500)] <EricDalquist> hrm
[15:33:32 CDT(-0500)] <sjungling> it did report a few conflicts:
[15:33:32 CDT(-0500)] <sjungling> Conflicts:
[15:33:32 CDT(-0500)] <sjungling> uportal-ear/pom.xml
[15:33:32 CDT(-0500)] <sjungling> uportal-war/src/main/resources/properties/contexts/datasourceContext.xml
[15:33:32 CDT(-0500)] <sjungling> uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml
[15:33:33 CDT(-0500)] <sjungling> but git automerged
[15:33:57 CDT(-0500)] <EricDalquist> ok
[15:34:18 CDT(-0500)] <EricDalquist> can do a gist that would let me view the diff of your person dir context
[15:34:22 CDT(-0500)] <EricDalquist> so create a new one
[15:34:25 CDT(-0500)] <EricDalquist> paste your functional config
[15:34:33 CDT(-0500)] <EricDalquist> and functional ehcache.xml conf
[15:34:34 CDT(-0500)] <EricDalquist> and save that
[15:34:39 CDT(-0500)] <EricDalquist> then paste in the new versions of each
[15:34:47 CDT(-0500)] <EricDalquist> I think that will let me view a diff of the two
[15:35:38 CDT(-0500)] <sjungling> https://gist.github.com/5128335a8ffa2e59b41b
[15:35:46 CDT(-0500)] <sjungling> that's the last working
[15:37:04 CDT(-0500)] <sjungling> and here's the diff from the attempts at caching https://gist.github.com/70b72004773272372639
[15:40:04 CDT(-0500)] <chris_cousquer> hi athena
[15:40:18 CDT(-0500)] * athena waves
[15:40:29 CDT(-0500)] <EricDalquist> sjungling: I am at a loss as to what is going on here
[15:40:39 CDT(-0500)] <EricDalquist> can you try just the ehcache.xml changes
[15:40:46 CDT(-0500)] <EricDalquist> and see if it all starts correctly
[15:40:54 CDT(-0500)] <EricDalquist> sorry I don't have better answers for tyou
[15:41:50 CDT(-0500)] <chris_cousquer> @athena We find what's going wrong with NEWSPLT-65 in other language than english
[15:41:50 CDT(-0500)] <sjungling> np, clean deploying now
[15:42:40 CDT(-0500)] <chris_cousquer> it's not a bug from AntiSami, it's fluid
[15:42:45 CDT(-0500)] <athena> yes
[15:42:51 CDT(-0500)] <athena> ok, i know exactly the bug you're talking about
[15:42:59 CDT(-0500)] <athena> it's really annoying and even shows up in english w/ special characters
[15:43:04 CDT(-0500)] <athena> do you know if antisamy has a patch for it now
[15:43:05 CDT(-0500)] <athena> ?
[15:43:12 CDT(-0500)] <athena> there's been some discussion in that community about it
[15:43:18 CDT(-0500)] <chris_cousquer> no it's not antiSami
[15:43:29 CDT(-0500)] <chris_cousquer> it's fluid
[15:43:49 CDT(-0500)] <athena> oh oh
[15:43:50 CDT(-0500)] <athena> sorry
[15:43:51 CDT(-0500)] <athena> ok
[15:43:54 CDT(-0500)] <athena> hmm
[15:44:09 CDT(-0500)] <athena> so one possible solution is that we have a close-to-finished alternate backbone implementation
[15:44:22 CDT(-0500)] <chris_cousquer> it comes from fluid.XMLEncode
[15:44:22 CDT(-0500)] <chris_cousquer> https://github.com/fluid-project/infusion/blob/master/src/webapp/framework/renderer/js/fluidParser.js#L417
[15:45:57 CDT(-0500)] <athena> ahh interesting!
[15:46:01 CDT(-0500)] <chris_cousquer> first, every times you have a title, a description in a rss feed
[15:46:11 CDT(-0500)] <athena> so two things: 1. should mention it to fluid and see what they have to say about it
[15:46:20 CDT(-0500)] <athena> and 2. might try out that alternate branch and see how it works
[15:46:25 CDT(-0500)] <chris_cousquer> it apply 5 times the replace function
[15:46:47 CDT(-0500)] <chris_cousquer> so it's slow
[15:47:07 CDT(-0500)] <sjungling> @EricDalquist looks like clean deployed & is up an running w/o issue with the modified ehcache.xml
[15:47:14 CDT(-0500)] <EricDalquist> great
[15:48:28 CDT(-0500)] <chris_cousquer> second, this may be have develop to fix & in url string
[15:48:39 CDT(-0500)] <EricDalquist> at this point I'd apply the cache wrappers in personDirectoryContext one at a time
[15:48:43 CDT(-0500)] <EricDalquist> and try
[15:48:47 CDT(-0500)] <EricDalquist> to see if we can narrow this down
[15:48:52 CDT(-0500)] <EricDalquist> since nothing is jumping out at me here
[15:50:56 CDT(-0500)] <EricDalquist> ok I have to run but I'll try to be back online in ~ 40 minutes
[15:51:02 CDT(-0500)] <sjungling> same here
[15:51:04 CDT(-0500)] <EricDalquist> I'll also read the chat logs
[15:51:16 CDT(-0500)] <athena> chris_cousquer: try out the https://github.com/Jasig/NewsReaderPortlet/tree/NEWSPLT-67 branch
[15:51:18 CDT(-0500)] <sjungling> thanks for your help
[15:51:24 CDT(-0500)] <chris_cousquer> so at UPMC we have patch fluid.XMLEncode to return only : return text; and it seems to work for the all portal
[15:51:47 CDT(-0500)] <EricDalquist> no problem sjungling we'll get this figured out 
[15:52:24 CDT(-0500)] <athena> that's good to know, chris_cousquer
[15:55:40 CDT(-0500)] <drewwills> EricDalquist and sjungling... you're probably way ahead of me (i'm catching up on the discussion)... but could there be potential issues with @Autowired on FactoryBean impls? https://jira.springsource.org/browse/SPR-4935
[15:56:19 CDT(-0500)] <drewwills> in my head i can imagine them each trying to do their work in the same magic time
[15:58:22 CDT(-0500)] <chris_cousquer> so I don't know if it's really a bug of fluid or the way we use fluid in newsreaderportlet, athena. I need to do more tests tomorrow and We will try the branch
[15:58:32 CDT(-0500)] <athena> excellent - let me know how it goes
[15:58:44 CDT(-0500)] <athena> i can tell you the title in mobile is sort of broken in that branch still, but i think the rest of it shoudl work
[15:59:12 CDT(-0500)] <chris_cousquer> ok
[16:04:45 CDT(-0500)] <sjungling1> here's something interesting…our OSA found that our Portal apps are querying our LDAP servers for the `guest` user a crazy amount of times… there a way to not search LDAP for the `guest` user?
[16:17:01 CDT(-0500)] <drewwills> yes sjungling1, you could use the RegexGatewayPersonAttributeDao... and also good caching would mitigate that I suppose
[16:20:36 CDT(-0500)] <sjungling1> @drewwills kk. working on the caching right now
[16:22:38 CDT(-0500)] <drewwills> also take a quick look at the IRC logs while you were briefly disconnected: https://wiki.jasig.org/display/UPC/uportal+IRC+Logs
[16:22:54 CDT(-0500)] <drewwills> i posted something, but i think my timing was pretty poor
[16:23:34 CDT(-0500)] <sjungling1> w/r/t @Autowired?
[16:24:05 CDT(-0500)] <drewwills> yes
[16:25:19 CDT(-0500)] <drewwills> i wouldn't call it a promising lead, though... it's not clear to me why that wouldn't be an error all the time, if that hypothesis was correct
[16:25:26 CDT(-0500)] <sjungling1> not sure it was related. think i got my personDirectory working w/ caching…
[16:25:27 CDT(-0500)] <sjungling1> https://gist.github.com/6fca3d482a378f72ef65
[16:25:56 CDT(-0500)] <sjungling1> rolled back to a working config and instead of trying to follow Eric's example, just started uncommenting
[16:26:06 CDT(-0500)] <sjungling1> and that seems to deploy