[08:17:33 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[09:00:04 EDT(-0400)] * athena7 (n=athena7@adsl-99-149-83-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:08:50 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543344.dsl.bell.ca) has joined ##uportal
[09:24:01 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:32:26 EDT(-0400)] * athena7 (n=athena7@adsl-99-184-128-151.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:37:42 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[09:45:39 EDT(-0400)] * agherna (n=agherna@panache.ci.uiuc.edu) has joined ##uportal
[10:12:26 EDT(-0400)] * bulloche (n=bulloche@134.250.4.77) has joined ##uportal
[10:19:39 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[10:46:59 EDT(-0400)] <EricDalquist> well adding a robots.txt to exclude fisheye from search engine crawling seems to have fixed our need to reboot
[10:47:31 EDT(-0400)] <EricDalquist> though it is annoying that the fisheye content won't be searchable other than through its own UI
[10:51:20 EDT(-0400)] <athena7> oh, interesting
[10:51:50 EDT(-0400)] <EricDalquist> fisheye was seeing around a total of 50 requests/minute just from robots
[10:51:57 EDT(-0400)] <athena7> wow.
[10:52:01 EDT(-0400)] <EricDalquist> lots of pages to index
[10:52:02 EDT(-0400)] <athena7> poor fisheye
[10:52:03 EDT(-0400)] <athena7> yeah
[10:52:08 EDT(-0400)] <EricDalquist> think of every revision of every file
[10:52:12 EDT(-0400)] <athena7> yeah
[10:52:12 EDT(-0400)] <EricDalquist> plus all of the diffs
[10:52:15 EDT(-0400)] <athena7> yeah
[10:52:16 EDT(-0400)] <athena7> 
[10:52:30 EDT(-0400)] <EricDalquist> so if you see it get unresponsive again let ScottB or I know
[10:52:39 EDT(-0400)] <EricDalquist> but right now the crond restart is off
[10:52:42 EDT(-0400)] <athena7> by the way, i'm having some weird problems with the ajax channel browser in the uportal trunk
[10:52:48 EDT(-0400)] <EricDalquist> yay
[10:52:49 EDT(-0400)] <athena7> i figured i'd broken something w/ the namespacing and fluid work
[10:52:55 EDT(-0400)] <athena7> but the post looks correct
[10:53:51 EDT(-0400)] <EricDalquist> what are the problems?
[10:54:05 EDT(-0400)] <athena7> http://uportal.pastebin.com/m13b2eeb1
[10:56:09 EDT(-0400)] <athena7> firing up my debugger
[11:05:30 EDT(-0400)] <athena7> oh ok, i think ti's just that i happened to pick a broken portlet
[11:05:35 EDT(-0400)] <EricDalquist> ah
[11:05:43 EDT(-0400)] <EricDalquist> which would fail to init
[11:06:03 EDT(-0400)] <athena7> yes 
[11:06:14 EDT(-0400)] <athena7> should probably do something about that, but at least it's not really broken
[11:20:39 EDT(-0400)] <athena7> so did i mention yesterday the IE drag and drop issue in up3?
[11:20:51 EDT(-0400)] <EricDalquist> yeah
[11:20:56 EDT(-0400)] <athena7> ok
[11:20:58 EDT(-0400)] <athena7> wanted to make sure
[11:20:59 EDT(-0400)] <EricDalquist> that it probably wont' get fixed until 3.1?
[11:21:04 EDT(-0400)] <athena7> well
[11:21:14 EDT(-0400)] <athena7> it will get fixed as soon as we migrate to the fluid reorderer
[11:22:10 EDT(-0400)] <EricDalquist> well that is the big feature pegged for 3.1
[11:22:19 EDT(-0400)] <athena7> yeah
[11:22:38 EDT(-0400)] <athena7> if they can find a workaround for the document.write issues that'd be so awesome
[11:22:42 EDT(-0400)] <athena7> the google portlet crashes my browser so hard
[11:22:55 EDT(-0400)] <EricDalquist> is that a related issue?
[11:27:01 EDT(-0400)] <athena7> well
[11:27:22 EDT(-0400)] <athena7> it's the result of an unfixed jquery bug, so it exists with both the present uportal drag and drop and with the fluid reorderer
[11:27:31 EDT(-0400)] <athena7> but fluid seems interested in trying to find a workaround
[11:35:48 EDT(-0400)] <athena7> so jQuery UI changed their packaging such that you can decide which components you'd like included and get back one big minified file
[11:36:02 EDT(-0400)] <athena7> which leaves the question of which components we think we'd like
[11:37:39 EDT(-0400)] <athena7> do we want to just include everything? try and target what the portal needs?
[11:37:57 EDT(-0400)] <EricDalquist> hrm
[11:38:25 EDT(-0400)] <EricDalquist> if namespacing worked well I would say minimal
[11:38:46 EDT(-0400)] <EricDalquist> but could that cause problems with other portlets using jquery?
[11:39:26 EDT(-0400)] <athena7> well, potentially
[11:39:33 EDT(-0400)] <athena7> it'd be best to include everything we need
[11:39:36 EDT(-0400)] <athena7> but nothing extra
[11:39:40 EDT(-0400)] <athena7> from a performance standpoint
[11:39:47 EDT(-0400)] <athena7> but different people may have different needs
[11:40:12 EDT(-0400)] <EricDalquist> yeah ...
[11:40:36 EDT(-0400)] <athena7> so we could include a default that probably works
[11:40:45 EDT(-0400)] <athena7> and let people replace it if necessary
[11:40:46 EDT(-0400)] <EricDalquist> for the portal world we really need a JS library that can be loaded from named files and loaded via passing in a namespace string
[11:41:06 EDT(-0400)] <athena7> but we want to make sure it has a unique name so that it can get perma-cached like we talked about
[11:41:09 EDT(-0400)] <EricDalquist> but I don't know enough JS to have any clue if that is possible or would work
[11:41:17 EDT(-0400)] <EricDalquist> yeah
[11:41:39 EDT(-0400)] <athena7> well we could go back to having separate files for each component
[11:41:49 EDT(-0400)] <athena7> better from a performance standpoint to combine it all, probably though
[11:42:39 EDT(-0400)] <EricDalquist> hrm
[11:42:43 EDT(-0400)] <athena7> from the yahoo documentation, which tuy mentioned before: http://developer.yahoo.com/performance/rules.html#num_http
[11:42:50 EDT(-0400)] <EricDalquist> yeah
[11:42:55 EDT(-0400)] <EricDalquist> it would be fewer request
[11:43:00 EDT(-0400)] <EricDalquist> and less http overhead
[11:43:09 EDT(-0400)] <athena7> i think it probably makes sense to just take a stab at what's likely necessary
[11:43:15 EDT(-0400)] <EricDalquist> I think we need to go to the dev list for this ... I really don't know
[11:43:18 EDT(-0400)] <athena7> and document it thoroughly
[11:43:23 EDT(-0400)] <athena7> yes, that's probably a good idea
[11:44:14 EDT(-0400)] <athena7> hm
[12:12:00 EDT(-0400)] <athena7> how many active branches do we have right now? is it just the trunk and rel-3-0-patches?
[12:12:11 EDT(-0400)] <EricDalquist> yeah
[12:12:13 EDT(-0400)] <athena7> ok
[12:12:15 EDT(-0400)] <EricDalquist> there was a gap branch
[12:12:19 EDT(-0400)] <athena7> and that's gone?
[12:12:20 EDT(-0400)] <EricDalquist> but it is kind of dead
[12:12:33 EDT(-0400)] <EricDalquist> I need to delete and recreate it once someone is actually going to do work on it
[12:13:03 EDT(-0400)] <athena7> ah ok
[12:13:12 EDT(-0400)] <athena7> so we don't need to worry about it for now anyway
[12:14:55 EDT(-0400)] <athena7> so when i do the fluid commits i guess i should block them from going into the 3-0-patches branch?
[12:15:09 EDT(-0400)] <EricDalquist> yeah
[12:15:16 EDT(-0400)] <athena7> ok
[12:15:20 EDT(-0400)] <EricDalquist> you've seen how to do that with svnmerge?
[12:15:30 EDT(-0400)] <athena7> i havent' done it, but i saw the documentation on it
[12:16:16 EDT(-0400)] <EricDalquist> similar to merge I think
[12:16:16 EDT(-0400)] <athena7> i think we can move over the namespacing and css stuff i did though
[12:16:22 EDT(-0400)] <EricDalquist> svnmerge block -r
[12:16:35 EDT(-0400)] <EricDalquist> sounds good, just be sure to do it in different commits
[12:16:43 EDT(-0400)] <athena7> yeah
[12:16:52 EDT(-0400)] <EricDalquist> or just plan on doing the commit directly on the patches branch
[12:16:54 EDT(-0400)] <EricDalquist> either works
[12:17:12 EDT(-0400)] <athena7> yeah
[12:17:26 EDT(-0400)] <athena7> for future stuff post-fluid integration i may have to just do separate commits
[12:17:27 EDT(-0400)] <athena7> we'll see
[12:17:46 EDT(-0400)] <EricDalquist> yup
[12:17:52 EDT(-0400)] <athena7> i added in the drag and drop bug and gave it appropriate affects and fix versions
[12:17:58 EDT(-0400)] <EricDalquist> eventually stuff dirgresses where it can't be easily merged
[12:17:59 EDT(-0400)] <athena7> so at least we'll have it documented for the 3.0 branch
[12:18:02 EDT(-0400)] <athena7> yeah
[12:18:03 EDT(-0400)] <EricDalquist> the poms are already like that
[12:18:06 EDT(-0400)] <athena7> i'm sure
[12:46:14 EDT(-0400)] * athena7 (n=athena7@adsl-99-149-83-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[13:23:20 EDT(-0400)] * glenda (n=ggonzale@uni1.unicon.net) has joined ##uportal
[13:28:09 EDT(-0400)] <EricDalquist> FYI .. the URL object is EVIL
[13:28:46 EDT(-0400)] <EricDalquist> it does blocking DNS lookups when you call .equals or .hashcode on it
[13:28:55 EDT(-0400)] <EricDalquist> and those values can CHANGE depending on what the DNS resolves to{color}
[13:31:45 EDT(-0400)] <athena7> yeah that whole class is evil
[13:31:52 EDT(-0400)] <athena7> that's um, great though
[13:32:05 EDT(-0400)] <EricDalquist> yeah
[13:32:10 EDT(-0400)] <athena7> doesn't some of the java dns stuff get cached inappropriately long as well?
[13:32:17 EDT(-0400)] <EricDalquist> forever
[13:32:23 EDT(-0400)] <athena7> yeah that's what i thought
[13:32:32 EDT(-0400)] <EricDalquist> used a Map<URL, Document> as my cache
[13:32:42 EDT(-0400)] <athena7> oh.
[13:32:44 EDT(-0400)] <EricDalquist> it was more expensive to use the URL as the key than just re-create the document
[13:32:50 EDT(-0400)] <athena7> wow.
[13:32:53 EDT(-0400)] <athena7> that's horrible!
[13:32:55 EDT(-0400)] <EricDalquist> because of the expense involved with calling .hashCode and .equals
[13:32:57 EDT(-0400)] <EricDalquist> yup
[13:33:06 EDT(-0400)] <EricDalquist> and there is neat stuff like:
[13:33:09 EDT(-0400)] <athena7> can you key it on the string value of the URL or something instead, or is that hideous as well?
[13:33:27 EDT(-0400)] <EricDalquist> new URL("http://foo.com").equals(new URL("http://bar.com"
;
[13:33:34 EDT(-0400)] <EricDalquist> that is true if they resolve to the same IP
[13:33:40 EDT(-0400)] <athena7> WHYYYYY
[13:33:41 EDT(-0400)] <athena7>
[13:33:44 EDT(-0400)] <EricDalquist> yeah
[13:34:00 EDT(-0400)] <EricDalquist> so I'm going to use the String used to create the URL as the key
[13:34:17 EDT(-0400)] <athena7> yeah that makes sense
[13:36:18 EDT(-0400)] <EricDalquist> and of course Sun can never fix URL
[13:36:24 EDT(-0400)] <EricDalquist> since people may depend on that behavior
[13:36:33 EDT(-0400)] <EricDalquist> great example of why API design is important 
[13:43:37 EDT(-0400)] * glendago (n=ggonzale@uni1.unicon.net) has left ##uportal
[13:44:07 EDT(-0400)] <athena7> yeah
[14:13:11 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:49:12 EDT(-0400)] <EricDalquist> he agherna is Drew anywhere near you?
[14:49:34 EDT(-0400)] <agherna> i think he may be coming back from lunch soon
[14:54:00 EDT(-0400)] <EricDalquist> could you ask him if he'd be willing to jump into irc for a few minutes?
[14:54:50 EDT(-0400)] <agherna> yes
[14:54:58 EDT(-0400)] <EricDalquist> thanks
[14:56:17 EDT(-0400)] <agherna> np
[14:57:56 EDT(-0400)] * lennar1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[14:58:59 EDT(-0400)] <len> wonder why it won't let me use 'lennard' am always assigned 'lennar1'
[14:59:28 EDT(-0400)] <EricDalquist> probably somone else on freenode using lennard
[14:59:35 EDT(-0400)] <EricDalquist> yup
[14:59:41 EDT(-0400)] <EricDalquist> do '/whois lennard'
[15:00:16 EDT(-0400)] <athena7> or /ns info lennard
[15:01:06 EDT(-0400)] <athena7> unfortunately people seem to be able to squat on accounts here for a while
[15:01:32 EDT(-0400)] <EricDalquist> well lenndard is actually on right now
[15:13:35 EDT(-0400)] <len> has anyone of you heard of uPortal being deployed in JBoss AS?
[15:14:52 EDT(-0400)] <athena7> yeah i think "athena" hasn't actually been used in almost a year
[15:17:28 EDT(-0400)] * awills (n=awills@ras117.admin.uillinois.edu) has joined ##uportal
[15:17:59 EDT(-0400)] * awills tries to stop his ears from ringing
[15:18:05 EDT(-0400)] <EricDalquist>
[15:18:10 EDT(-0400)] <awills> hey folks
[15:18:21 EDT(-0400)] <len>
[15:18:22 EDT(-0400)] <EricDalquist> hey
[15:18:41 EDT(-0400)] <EricDalquist> my head is hurting from ideas/issues with this crn object caching stuff
[15:18:58 EDT(-0400)] <EricDalquist> now I'm contemplating threadlocals for objects that are re-usable but not threadsafe
[15:19:05 EDT(-0400)] <EricDalquist> instead of an object pool
[15:19:13 EDT(-0400)] <awills> oh my
[15:19:17 EDT(-0400)] <EricDalquist> just because the TLs would be easier to code
[15:19:25 EDT(-0400)] <EricDalquist> like reading the dom4j docs
[15:19:42 EDT(-0400)] <EricDalquist> their Element is not necessarily threadsafe
[15:20:05 EDT(-0400)] <awills> ahhh, yeppers
[15:20:08 EDT(-0400)] <EricDalquist> either is a ScriptEngine depending on the return value of an attribute
[15:20:13 EDT(-0400)] <EricDalquist> either is a Transformer
[15:20:19 EDT(-0400)] <EricDalquist> but all are really freaking expensive to create
[15:22:43 EDT(-0400)] <awills> would we have better performance creating these objects once and synchronizing on their use then?
[15:23:26 EDT(-0400)] <EricDalquist> for import/export
[15:23:27 EDT(-0400)] <EricDalquist> yes
[15:23:29 EDT(-0400)] <EricDalquist> well no
[15:23:44 EDT(-0400)] <EricDalquist> because one of the eventual steps is to thread these things
[15:23:53 EDT(-0400)] <awills> yes, exactly
[15:23:54 EDT(-0400)] <EricDalquist> and for like the Element how do you sync?
[15:23:58 EDT(-0400)] <EricDalquist> phrase returns an object
[15:24:01 EDT(-0400)] <EricDalquist> then other stuff acts on it
[15:24:05 EDT(-0400)] <EricDalquist> so there is no way to sync it
[15:24:33 EDT(-0400)] Wiki Markup <awills> <synchronized on="${myObj}"><do-stuff/></sychronized>
[15:24:36 EDT(-0400)] <EricDalquist> yeah
[15:24:55 EDT(-0400)] <EricDalquist> that would defeat the use of threading the tasks for added performance
[15:25:19 EDT(-0400)] <EricDalquist> if it is a command line scripting tool like we use it for uPortal ThreadLocals make sense
[15:25:35 EDT(-0400)] <EricDalquist> there aren't going to be many threads and the app has a finite run time so cleanup isn't an issue
[15:25:49 EDT(-0400)] <EricDalquist> for using it in a long-running app that isn't really that great though
[15:25:55 EDT(-0400)] <EricDalquist> a real cache and object pools would be better
[15:26:02 EDT(-0400)] <EricDalquist> as they can be configured to drop unused objects
[15:26:16 EDT(-0400)] <awills> yeah
[15:26:17 EDT(-0400)] <EricDalquist> but they are a bit more overhead
[15:26:29 EDT(-0400)] <EricDalquist> and I still have no idea how we're going to do this in phrases
[15:26:54 EDT(-0400)] Wiki Markup <EricDalquist> though I guess we could create <pool target="${phrase()}">
[15:27:06 EDT(-0400)] <awills> we might have to implements some of the more complex bits in tasks
[15:27:26 EDT(-0400)] <EricDalquist> on the plus side
[15:27:34 EDT(-0400)] <EricDalquist> my hackish solutions do good things
[15:27:52 EDT(-0400)] <EricDalquist> with just the scriptengine and dom caching I went from 47 seconds to 20 seconds for 286 layouts
[15:28:14 EDT(-0400)] <EricDalquist> that doesn't include XSLT caching or script compilation
[15:28:14 EDT(-0400)] <awills> yes, that's a big difference
[15:28:27 EDT(-0400)] <EricDalquist> which I think would at least halve it again
[15:30:42 EDT(-0400)] <awills> according to my quick math... at 28.6 layouts a second, that's 3,496 seconds for 100k layouts (58 minutes)
[15:30:51 EDT(-0400)] <EricDalquist> yup
[15:30:58 EDT(-0400)] <EricDalquist> getting much more reasonable
[15:31:10 EDT(-0400)] <awills> 100k is a lot of layouts
[15:31:15 EDT(-0400)] <EricDalquist> yeah
[15:31:23 EDT(-0400)] <EricDalquist> we haven't done any user purging yet either
[15:31:32 EDT(-0400)] <EricDalquist> so our db actually has ~ 160k users in it
[15:31:49 EDT(-0400)] <EricDalquist> with layouts for those that have made customizations (don't have a total on that but we're assuming it is over 50%)
[15:31:59 EDT(-0400)] <EricDalquist> so
[15:32:07 EDT(-0400)] <awills> if you can get a feed of the users to remove, you can use crn-delete -Dtype=user to prune them
[15:32:16 EDT(-0400)] <EricDalquist> yeah
[15:32:19 EDT(-0400)] <EricDalquist> we're going to
[15:32:27 EDT(-0400)] <EricDalquist> actually I think we're going to modify the scripts a bit
[15:32:34 EDT(-0400)] <EricDalquist> so we can give it a list of 'removed' users
[15:32:37 EDT(-0400)] <EricDalquist> and just not export them
[15:32:47 EDT(-0400)] <awills> ah sure
[15:32:51 EDT(-0400)] <EricDalquist> once we're post-update we're supposed to be hooking up into the deactivation process
[15:32:52 EDT(-0400)] <awills> that works too
[15:33:12 EDT(-0400)] <EricDalquist> so are you still ok with having a top level CACHE request attribute?
[15:33:39 EDT(-0400)] <awills> like I talked about? set by the ScriptRunner?
[15:34:17 EDT(-0400)] <EricDalquist> yeah
[15:34:20 EDT(-0400)] <awills> that's something I've had my eye on for a few months at least
[15:34:28 EDT(-0400)] <EricDalquist> right now I have it looking at the incoming request
[15:34:39 EDT(-0400)] <EricDalquist> and only creating a Map for caching if one doesn't already exist
[15:35:08 EDT(-0400)] <awills> can you post an example to pastebin?
[15:35:10 EDT(-0400)] <EricDalquist> I was going to deffer to you on how exactly to code that part to make it flexible so someone could change it to use something more complex like a EHCache if they wanted
[15:35:20 EDT(-0400)] <awills> (so i can follow you better)
[15:35:40 EDT(-0400)] <awills> yeah makes sense
[15:35:45 EDT(-0400)] <EricDalquist> http://uportal.pastebin.com/m6a01ff0b
[15:35:58 EDT(-0400)] <EricDalquist> that is in public TaskResponse run(Task k, TaskRequest req, TaskResponse res) {
[15:41:57 EDT(-0400)] <awills> i suspect this version would work just fine: http://uportal.pastebin.com/m75726f17
[15:42:23 EDT(-0400)] <awills> but it's a small difference
[15:42:38 EDT(-0400)] <EricDalquist> are you ensured you will have a RuntimeRequestResponse?
[15:42:51 EDT(-0400)] <EricDalquist> the blind cast just makes me nervous
[15:44:48 EDT(-0400)] <awills> yeah you're right – it's possible for someone to pass in something of their own... and future developments could make a CCE more likely on new ways
[15:49:12 EDT(-0400)] <awills> in that case how 'bout this: http://uportal.pastebin.com/mc33f826
[15:49:30 EDT(-0400)] <awills> it just seems odd to wrap it twice
[15:51:14 EDT(-0400)] <awills> I think this approach – just putting in a Map, for now, if it's not already there – is a decent one to start with. If we need more sophistication in the default CACHE in the future, we can add it.
[15:55:09 EDT(-0400)] <EricDalquist> well it doesn't wrap it twice
[15:55:11 EDT(-0400)] <EricDalquist> just once
[15:55:20 EDT(-0400)] <EricDalquist> but the logic is in two places since either may or may not happen
[15:55:43 EDT(-0400)] <awills> yeah, i see now
[15:56:49 EDT(-0400)] <awills> but if there are potentially 2 things that can be added in that method, there's much more likelihood that we'll be using the wrapper... might as well be 100% likelihood
[15:57:05 EDT(-0400)] <EricDalquist> yeah
[15:59:28 EDT(-0400)] <EricDalquist> so a CacheTask and a PoolTask would be extensions of SetAttributeTask
[15:59:37 EDT(-0400)] <awills> I'm good with this enhancement... and furthermore: the technology-specifiac thread safety considerations you're looking at suggest that we're better off leveraging the CACHE in tasks/phrases like <xslt> and $
, b/c these things know what their dealing with and can make appropriate choicesWiki Markup {doc}{doc}
[15:59:52 EDT(-0400)] <EricDalquist> brb
[16:02:27 EDT(-0400)] <awills> instead of a pool, what if the <xslt> task leveraged the CACHE and a ThreadLocal in combination?
[16:04:40 EDT(-0400)] <awills> *"in tasks/phrases like <xslt> and $
(as opposed to <with> and <with-attribute>)"Wiki Markup {doc}{doc}
Page Comparison
General
Content
Integrations