uPortal IRC Logs-2011-02-15

Owned by Apereo Infrastructure
Last updated: Feb 15, 2011Version comment
9 min read

[09:51:09 CST(-0600)] <b-rock> Greetings uPortal Devs: I'm getting an exception deploying the latest weather portlet http://uportal.pastebin.com/T99Z8VLL the error says it cannot find the file, but when I check for the file it does exist in that location. Has anyone else here worked around an issue like this one?
[09:52:15 CST(-0600)] <athena> no, i haven't seen any errors like that or heard one reported
[09:54:48 CST(-0600)] <b-rock> thanks athena: I think the error has to do with the pluto invoker servlet mappings. If I leave that servlet and mapping out of the web.xml file, the portlet deploys but does not load if you try to add the portlet to a page.
[09:55:27 CST(-0600)] <athena> are you using the portal's ant task to deploy the portlet?
[09:56:34 CST(-0600)] <b-rock> no. we are using hot deploys into the tomcat webapps folder. This is the first time I've seen where manually adding the PlutoInvoker servlet mappings to web.xml does not seem to work properly.
[09:57:51 CST(-0600)] <holdorph> does a command line deploy work?
[09:58:12 CST(-0600)] <holdorph> if it does, maybe you could compare the command line deployed web.xml to your hand modified web.xml
[10:01:13 CST(-0600)] <b-rock> yeah. I'm gonna leave it out and try to deploy it from the command line to see if there's some kind of difference. Thanks holdorph
[10:33:25 CST(-0600)] <b-rock> ugh. After manually deploying the portlet with no success. I went for the old fashioned restart tomcat and re hot deploy the war (our normal way) and the portlet now works.
[10:33:52 CST(-0600)] <b-rock> rather the paste bin from above went away.
[11:19:10 CST(-0600)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist!~apollo@adsl-76-208-69-56.dsl.mdsnwi.sbcglobal.net on 10:58:24 CST(-0600)
[11:42:30 CST(-0600)] <EricDalquist> athena: I'm trying to remember what combo of settings worked for postgres yesterday
[11:42:43 CST(-0600)] <athena> changing the type to "text"
[11:42:44 CST(-0600)] <EricDalquist> was it @Type(type = "text")
[11:42:46 CST(-0600)] <EricDalquist> ok
[11:42:47 CST(-0600)] <athena> yep
[11:42:49 CST(-0600)] <EricDalquist> that's what I though
[11:42:56 CST(-0600)] <EricDalquist> for some reason it just worked for me on oracle this morning
[11:42:58 CST(-0600)] <EricDalquist> I thought it didn't
[11:43:03 CST(-0600)] <EricDalquist> testing again from a clean initportal
[11:43:25 CST(-0600)] <EricDalquist> http://community.jboss.org/wiki/HibernateCoreMigrationGuide35 and http://community.jboss.org/wiki/HibernateCoreMigrationGuide36 make me think they tinkered a lot with CLOB
[11:43:37 CST(-0600)] <EricDalquist> so we'll see what my testing now comes up with
[11:43:50 CST(-0600)] <EricDalquist> if it fails like I thought it was I'm going to post on the forums
[12:08:16 CST(-0600)] <EricDalquist> https://forum.hibernate.org/viewtopic.php?f=1&amp;t=1009568
[12:14:01 CST(-0600)] <EricDalquist> athena: it also worked with @Lob if the get methods were marked Transactional right?
[12:14:14 CST(-0600)] <athena> yes, that's correct
[12:14:38 CST(-0600)] <EricDalquist> I'm re-reading the hibernate docs on transactions
[12:14:51 CST(-0600)] <EricDalquist> they are actually very explicit that you should never be interacting with the DB outside of a TX
[12:14:57 CST(-0600)] <EricDalquist> so maybe that is actually the correct solution
[12:15:04 CST(-0600)] <EricDalquist> it would make sense for getting consistent data too
[12:15:42 CST(-0600)] <EricDalquist> since lots of our POJOs use multiple tables
[12:16:02 CST(-0600)] <EricDalquist> in theory right now a read could get data from table A before a commit and data from table B after a commit
[12:16:16 CST(-0600)] <athena> ah ok
[12:16:17 CST(-0600)] <athena> that makes sense
[12:16:36 CST(-0600)] <EricDalquist> also I dug out the conversations that gave me these concerns
[12:16:39 CST(-0600)] <EricDalquist> and I think they are gone
[12:16:53 CST(-0600)] <EricDalquist> the issues were things lfuller had found early on around portlet entity persistence
[12:17:11 CST(-0600)] <EricDalquist> but now that entities are only stored if they actually have preferences we have many fewer entity objects
[12:17:17 CST(-0600)] <EricDalquist> so less contention on that table
[12:18:00 CST(-0600)] <athena> (smile)
[12:36:06 CST(-0600)] <EricDalquist> uhg so I'm still a bit worried about this
[12:36:44 CST(-0600)] <EricDalquist> adding @Transactional(readOnly=true) to all of our getter DAO methods results in 286 transactions on the initial portal view
[12:37:01 CST(-0600)] <athena> yikes
[12:37:07 CST(-0600)] <EricDalquist> the other option is we try out the TX per request pattern
[12:37:08 CST(-0600)] <athena> that sounds like a lot :/
[12:37:08 CST(-0600)] <EricDalquist> yeah
[12:37:09 CST(-0600)] <EricDalquist> it is
[12:37:50 CST(-0600)] <EricDalquist> my worry with the tx/request approach is what does the failure look like when a TX commit results in a constraint failure
[12:38:02 CST(-0600)] <EricDalquist> I think the stack trace would come from the request filter
[12:38:05 CST(-0600)] <EricDalquist> and not the DAO code
[12:38:08 CST(-0600)] <athena> ah
[12:38:09 CST(-0600)] <athena> hmmm
[12:38:14 CST(-0600)] <athena> yeah that seems weird
[12:38:41 CST(-0600)] <EricDalquist> any thoughts on this lfuller?
[12:40:05 CST(-0600)] <lfuller> holy cow... that is huge
[12:40:17 CST(-0600)] <EricDalquist> yeah
[12:40:44 CST(-0600)] <EricDalquist> so right now have an OpenEntitytManagerInRequest servlet filter setup
[12:41:09 CST(-0600)] <EricDalquist> so pretty much any request to the portal results in an EntityManager being created and shared among all DB access for the life of the request
[12:41:30 CST(-0600)] <EricDalquist> but we only use transactions around create/update/delete DAO methods
[12:42:04 CST(-0600)] <EricDalquist> reading the hibernate docs they recommend to always be within a TX when doing DB access
[12:42:22 CST(-0600)] <EricDalquist> and right now it looks like we might have to do that when reading @Lob annotated fields from postgres
[12:42:33 CST(-0600)] <lfuller> not really.. no
[12:43:58 CST(-0600)] <EricDalquist> from 13.1.1. Unit of work in their manual:
[12:43:58 CST(-0600)] <EricDalquist> Hibernate disables, or expects the application server to disable, auto-commit mode immediately. Database transactions are never optional. All communication with a database has to occur inside a transaction. Auto-commit behavior for reading data should be avoided
[12:44:31 CST(-0600)] <EricDalquist> right now we are in auto-commit mode when reading but that doesn't really result in TX setup/teardown around every select
[12:45:16 CST(-0600)] <lfuller> sorry... am in a meeting here.
[12:45:24 CST(-0600)] <EricDalquist> no problem
[12:45:46 CST(-0600)] <lfuller> my experience with the read only flag was with the hibernate native api. Not JPA
[12:54:12 CST(-0600)] <EricDalquist> arg, well hopefully the hibernate folks can come up with a better answer than using a TX to read those @Lob fields
[12:57:39 CST(-0600)] <EricDalquist> uhg ... apparently most of those TXs are from loading portlet definition objects
[12:58:12 CST(-0600)] <EricDalquist> with @Transactional(readOnly=true) only on the definition and entity DAO getter methods we save a whoping 7 tx
[12:58:16 CST(-0600)] <EricDalquist> down to 279
[13:01:14 CST(-0600)] <holdorph> I can't contribute a lot here, but one question I have, is even without the transactions, does that mean you'd have 280'ish calls to the database?
[13:01:23 CST(-0600)] <EricDalquist> no
[13:01:34 CST(-0600)] <EricDalquist> we rely very heavily on the hibernate 1st/2nd level caches
[13:02:08 CST(-0600)] <EricDalquist> the problem is we have to stick the TX demarcation around the DAO method
[13:02:16 CST(-0600)] <EricDalquist> which is before we know if there is a cache hit or not
[13:03:58 CST(-0600)] <EricDalquist> for example the hibernate stats after that first page view are 44 2nd level misses and 175 hits
[13:04:17 CST(-0600)] <EricDalquist> so that's only ~50 queries to the DB on a cold start
[13:04:50 CST(-0600)] <EricDalquist> actually I miss-read that
[13:04:53 CST(-0600)] <holdorph> for just the first user or for every user who hasn't logged in since the last restart?
[13:05:00 CST(-0600)] <EricDalquist> it ran 26 queries
[13:05:05 CST(-0600)] <EricDalquist> first users
[13:05:18 CST(-0600)] <EricDalquist> most of the stuff that needs loading are portlet definition object
[13:05:28 CST(-0600)] <holdorph> users?
[13:05:37 CST(-0600)] <EricDalquist> er first user
[13:05:40 CST(-0600)] <holdorph> ok
[13:06:15 CST(-0600)] <EricDalquist> going to restart and get some more specific #s
[13:06:52 CST(-0600)] * holdorph has to meet someone for lunch, back in 60 minutes or so...
[13:17:06 CST(-0600)] <EricDalquist> https://mywebspace.wisc.edu/dalquist/web/JA-SIG/uP33HibernateScreenshots/
[13:17:11 CST(-0600)] <EricDalquist> if people are interested
[13:17:21 CST(-0600)] <EricDalquist> screenshots of the hibernate stats in jconsole
[13:18:00 CST(-0600)] <EricDalquist> 1 query, 18 cache hits right after startup
[13:18:19 CST(-0600)] <EricDalquist> guest view results in 12 queries and 11hits/12misses
[13:18:52 CST(-0600)] <EricDalquist> admin login is 23 more queries with 19/35 overall hit/miss
[13:19:10 CST(-0600)] <EricDalquist> admin logout is 1 more query 24/36 hit/miss
[13:19:44 CST(-0600)] <EricDalquist> student login is 14 queries 33/55 hit/miss
[13:19:54 CST(-0600)] <EricDalquist> most of the per-user queries are seeing if they have portlet entity objects
[13:48:02 CST(-0600)] <athena> EricDalquist: i can't seem to remember which file it is that has allt he cache tuning stuff
[13:48:09 CST(-0600)] <EricDalquist> ehcache.xml
[13:48:11 CST(-0600)] <athena> OH
[13:48:12 CST(-0600)] <athena> right.
[13:48:13 CST(-0600)] <athena> thanks (smile)
[13:48:21 CST(-0600)] <EricDalquist> are you in trunk right now?
[13:48:24 CST(-0600)] <EricDalquist> or some other version
[13:48:29 CST(-0600)] <athena> 3.2
[13:48:30 CST(-0600)] <athena> got it (smile)
[13:48:31 CST(-0600)] <EricDalquist> ok
[13:48:37 CST(-0600)] <athena> was looking at cacheContext.xml
[13:48:48 CST(-0600)] <athena> knew that wasn't what i wanted
[13:48:49 CST(-0600)] <athena> thanks
[13:48:49 CST(-0600)] <EricDalquist> ah yeah that just sets up the beans
[14:52:23 CST(-0600)] <rickard> In a portlet, if an action needs to update the database, it would make sense to do that from processAction(), right? As opposed to doing it in doView(). I'm updating an old portlet that some consultant wrote and it appears his processAction is pretty much empty whereas his doView does all kinds of stuff.
[14:54:26 CST(-0600)] <holdorph> yes, things that mutate the state of the portlet, including back end services like a database, should happen in processAction
[14:54:59 CST(-0600)] <rickard> Great, thanks. I have some rewriting to do (smile)
[14:55:07 CST(-0600)] <holdorph> you can do it in render (doView) but you have to be very very very careful to code your own guard conditions to make sure it doesn't execute more then once
[14:55:22 CST(-0600)] <rickard> Yeah.
[14:55:23 CST(-0600)] <holdorph> because a portlet's doView() might be called multiple times even when a user is NOT interacting with that portlet
[14:55:38 CST(-0600)] <holdorph> but a processAction is guaranteed to not be called multiple times
[14:55:44 CST(-0600)] <rickard> It's similar to Page_Load() vs events in ASP.NET.
[14:55:48 CST(-0600)] <holdorph> unless the user continues to interact with the portlet.
[14:56:27 CST(-0600)] <holdorph> I've never coded or learned anything about micrsoft technologies, so I'll take your word for it.
[14:56:27 CST(-0600)] <rickard> Just curious, how can doView() be called even though the user isn't interacting with the portlet?
[14:56:37 CST(-0600)] <holdorph> if the user is interacting with another portlet on the page
[14:56:45 CST(-0600)] <rickard> Ah, of course.
[14:56:54 CST(-0600)] <holdorph> all portlets on the page are asked to render
[14:56:54 CST(-0600)] <holdorph> if they are not cached
[14:58:59 CST(-0600)] <rickard> Thanks. One more quick question. In ASP.NET, you can give any HTML tag the attribute runat="server" which then means you can access it from code and, for example, hide or unhide it. Very convenient for hiding and unhiding blocks of markup. Is something similar possible with JSP?
[15:00:05 CST(-0600)] <rickard> Or is that a feature of something like Spring?
[15:03:13 CST(-0600)] <holdorph> i'm not sure I understand what you're even describing in ASP.NET. I'm tempted to say I don't know of anything like that in JSP, but it might be I'm just not understanding.
[15:09:23 CST(-0600)] <rickard> Ok. Here's an example.
[15:11:14 CST(-0600)] <rickard> The user submits a form and everything goes according to plan. I then want to display a message to the user and hide the form. In ASP.NET, I would do that by adding runat="server" to the form tag and set its visibility to false from the equivalent of processAction().
[15:11:31 CST(-0600)] <rickard> I've seen an attribute rendered=true/false, but I believe that's in Spring.
[15:12:50 CST(-0600)] <holdorph> there's definitely a lot of rich functionality in the Spring MVC JSP tag library. It would definitely help you accomplish something very close.
[15:13:59 CST(-0600)] <rickard> Ok, I'll look into that. Thanks.
[15:14:05 CST(-0600)] <holdorph> And technically you'd probably still be tied in a little bit to the controller functionality to actually have processed the form and filled/not-filled the errors object (cant remember what it's called off hand)
[15:31:48 CST(-0600)] <rickard> I've added a custom channel parameter (via SharedParameters.cpd) that sets whether a portlet is displayed in tab/normal view or not. I use the parameter to have certain portlets only work in focused mode. In my theme xml, I look for the parameter and only output portlets that should be displayed. This works, but it appears doView is called regardless.
[15:32:42 CST(-0600)] <rickard> In other words, even though a portlet is hidden from view in the xsl, uPortal seems to run the portlet.
[15:37:32 CST(-0600)] <holdorph> ok.
[15:38:13 CST(-0600)] <holdorph> if your goal is to only have the portlet 'do work' when it's in focused mode, you can check the portlet window state in the doView method and just exit early if it's not maximized.
[15:38:47 CST(-0600)] <holdorph> doView might still be called, but if it exits out after one if test, that's not a huge deal.
[15:39:15 CST(-0600)] <holdorph> you can also turn portlet caching on. While the user doesn't interact with the portlet, which if it's not displayiong they'll have no chance to do, then the cache will be valid
[15:39:27 CST(-0600)] <holdorph> when the cache is valid, doView won't even be called.
[15:40:12 CST(-0600)] <rickard> Ok, makes sense.