Re: [uportal-dev] uPortal 3.2.2 load issues
Pearson's HE Portal is going to be going to uPortal 3.1.x soon and we have been doing some performance testing. The only issue I've ran into was in the event that all users were users new to uPortal. The problem was not that uPortal 3.1.x did not handle the load, but that it did so a good deal slower than uPortal 2.6.1. In spite of that my laptop was able to handle 600 concurrent users which resulted in 18k new logins in roughly a half hour. I have a patch which will be uploaded some time today or tomorrow which significantly narrows the gap between uPortal 2.6.1 and uPortal 3.1.x. What the patch impacts is the same for all uPortal 3.x versions from 3.0 to present. With this patch, uPortal is fast enough to meet Pearson's needs. I do think that there is some further room for performance improvement, but since uP3 is now 'fast enough' it is unlikely I'll get the time to make further improvements. As far as missing indices... I've noticed that the same indices that were missing in older versions of uPortal appear to be missing in the newer. For example, no index on USER_NAME in the UP_USER table. Many institutions probably have no need for that index though. For Pearson, we can have upwards of 14+ million users, and tend to end up adding indices that would not be necessary elsewhere. In my experience, if you aren't dealing with nothing but new users, the limiting facter is rarely the portal, and typically the portlets (that is unless uPortal has not been configured/tuned properly). -Lennard - Original Message - From: Benito J. Gonzalez bgonzal...@ucmerced.edu To: uportal-dev@lists.ja-sig.org Sent: Monday, August 23, 2010 8:36:27 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] uPortal 3.2.2 load issues Hi All, Has anyone had performance issues with the latest release under load? We see a large difference in performance between our current 3.0.2 release and 3.2.2. CPU and memory usage were low. My guess is there are missing indices. We did some optimization of our 3.0.2 db but no optimization of 3.2.2. Any other ideas to check? Thanks, -- Benito J. Gonzalez Manager, Enterprise Web Application Development Information Technology Department University of California, Merced Desk: 209.228.2974 Cell: 209.201.5052 Email: bgonzal...@ucmerced.edu -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: lful...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Fwd: uPortal Peformance
Do the tomcats for all 3 have similar configurations? Am especially interested in any sort of compression/gzip configs. Have you used the yslow plugin to compare the versions of uPortal? If so... are there any new suggestions with the later versions or decreases in ratings for specific areas? With regards to uPortal, have there been any new tweaks/changes/additions to the JPA code since 3.0? Are the test users you are using new to uPortal (does a new layout have to be generated and persisted) or are you reusing the same users for each test? What you describe sounds very similar to what we ran into with the original 2.6.1 vs 3.0 perf testing. Those tests turned up a number of issues ranging from some functional, but performance killing JPA issues (easily fixed), to a pluto bug that Eric fixed. Think we saw 5 or 6 issues in all. Same sort of behavior... all versions were pretty comparable until a tipping point was reached and 3.0 couldn't handle the load. After the issues were fixed, 3.0 was actually faster in some respects and was definitely comparable to 2.6.1. uPortal 3.1 and 3.2 have had a lot of development done and are fully functional, but I doubt anyone has seriously pushed them as hard as you are now. The causes are likely going to vary a good deal, but I would focus on what is new in 3.1/3.2 since the latest point releases of 3.0 proved to be sufficiently performant with a very similar set of tests. Taking that approach should reduce the amount of code to look at... since the changes between 2.6.1 and 3.1 or 3.2 are far greater than those of 3.0 to 3.1 or 3.2. -Lennard - Original Message - From: Alex Bragg abr...@unicon.net To: uportal-dev@lists.ja-sig.org Sent: Monday, June 7, 2010 10:13:54 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Fwd: uPortal Peformance Hello, I'm doing some performance testing, and I could use some hints on a couple of issues. First, I'm looking for some hints on things I can tweak in 3.1.1/3.2.1 to improve performance under heavy load. Second, I'm hitting a bug in 2.6.1 that is preventing me from gathering solid baseline performance numbers, and perhaps someone else has seen it. Let me explain in further detail. We have been preparing for an upgrade of our production systems from uPortal 2.6.1 to uPortal 3.x. Currently, we're looking at two 3.x versions, 3.1.1 and 3.2.1. In my development environment, I have installed 2.6.1, 3.1.1, and 3.2.1. My 2.6.1 install is running out of a 5.5.28 Tomcat, and my 3.x versions are running in a 6.0.24 Tomcat. All versions are running under Java version 1.6.0_12-b04, 64-bit, and I have an Oracle 11gR2 database backing them. The layout in each instance is a simple 5-tab layout, with nothing on the default tab. I have a custom testing portlet that simply executes a SQL query 5, 10, or 15 times and renders a 3-line text output. On the remaining four tabs, I have mixtures of two or more of these testing portlets. I run tests with JMeter, and the click path is get login page, login, click tab 2, click tab 3, click tab 4, click tab 5, and logout. JMeter verifies each page renders properly. The tests I run execute this click path 4000 times spread across 1, 4, 50, and 200 threads, and there are no waits built into the scripts. Here are results from the tests I have run so far. The values are the 90th percentile page-response time in seconds. Please note that the number for 2.6.1 in the 200-thread column isn't valid. At the 200-thread level most of the 200 threads complete their 20 iterations before JMeter starts additional threads during ramp-up. I end up with no more than 4 or 5 threads running concurrently. Another thing that skews these numbers is that I can only get valid results using users that have successfully logged in before. Anything above 2 threads with users that have not previously logged in results in channels failing to render (with the message You are not authorized to view this channel). version 1 4 50 200 50-lb2 200-lb2 50-lb4 200-lb4 2.6.1 0.070.080.7 *0.08* 0.694.56 3.1.1 0.090.091.967.811.186.021.125.49 3.2.1 0.170.187.0426.43 6.1720.22 The lb2 and lb4 designators signify that I have started multiple Tomcats on the server, 2 for lb2 and 4 for lb4, and I'm balancing load with HAProxy. I see much better utilization on the server, and both page-response times and elapsed test run times (below) both improve significantly even though I have not added any additional hardware. This table shows the elapsed time in seconds to complete the above tests. version 1 4 50 200 50-lb2 200-lb2 50-lb4 200-lb4 2.6.1 934 454 216 212 209.09 263.43 3.1.1 1,537 462 495 813 386.92 660.39 421.41 414.32 3.2.1 3,299 862 1,999 3,958 1259.99
Re: [uportal-dev] uPortal and JDK support
+1 - Original Message - From: Eric Domazlicky edomazli...@tacomacc.edu To: uportal-dev@lists.ja-sig.org Sent: Monday, November 30, 2009 3:55:29 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: RE: [uportal-dev] uPortal and JDK support Dropping JDK 5 support makes sense to me. -Original Message- From: bounce-8723186-20145...@lists.wisc.edu [mailto:bounce-8723186-20145...@lists.wisc.edu] On Behalf Of Cris J Holdorph Sent: Monday, November 30, 2009 2:18 PM To: uportal-dev@lists.ja-sig.org Subject: [uportal-dev] uPortal and JDK support How do people feel about JDK support and uPortal? Sun has dropped support for JDK 5 back in October. We have the next major release of uPortal, 3.2, coming out as a release candidate shortly. Recently a bug was introduced by some code that only built with JDK 6. Is it worth considering only supporting JDK 6 with uPortal 3.2? With some caveat, that it *might* run on JDK 5, but developers are not committed to compiling/running/testing against JDK 5. If we do NOT consider the above then we need to know what we're telling ourselves. To avoid the issue that Adam introduced, we must actually USE JDK 5, to build against, because just using JDK 6 in compile for java 5 mode, doesn't eliminate the prossibility of being compile time dependent on a JDK class difference. My personal preference would be to no longer officially support JDK 5, now that Sun is no longer officially supporting it. Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: edomazli...@tacomacc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: lful...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Nominating Jen Bourey for uPortal Project Steering Committee
+1 Jen Bourey - Original Message - From: Andrew Petro ape...@unicon.net To: uportal-dev@lists.ja-sig.org Sent: Thursday, June 11, 2009 5:02:15 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Nominating Jen Bourey for uPortal Project Steering Committee uPortal developers, I'd like to nominate Jen Bourey as a uPortal developer representative to the uPortal Steering Committee. I believe Jen needs no introduction to the community of uPortal committers, but I'd nonetheless take a moment to remind of her recent and ongoing contributions to uPortal. Ohloh credits Jen with more than 200 commits to the uPortal codebase (which feels awfully low, in part because Jen has been a leader or major contributor to several Jasig portlet projects, including the Calendar portlet , the Feedback portlet , and the Tabbed Search portlet ). Jen has given several popular Jasig conference presentations about uPortal, including on JavaScript in uPortal 3, on using AJAX to improve the user experience, on uPortal 3 configuration and deployment automation, and on open source portlet incubation. Jen regularly posts to this developer email list and has answered many questions on the uportal-user@ email list. She is also regularly available and active in the uPortal IRC channel. In short, I believe Jen is eminently qualified to represent uPortal developers on the uPortal project steering committee and I would expect she would bring enthusiasm, technical competence, and particularly attention to continuing to grow the set of portlets and the quality of the user experience in uPortal. With many thanks to Jen for all her contributions to uPortal, Andrew - Original Message - From: Jonathan Markow jjmar...@ja-sig.org To: uportal-dev@lists.ja-sig.org Cc: uPortal PSC uportal-steering-commit...@lists.ja-sig.org, cas-steering-commit...@lists.ja-sig.org, JA-SIG Board bo...@lists.ja-sig.org Sent: Wednesday, June 10, 2009 8:48:29 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Developer Representatives to Project Steering Committees Developers: You have received a couple of emails recently about the Jasig 2009 Elections, during which our membership will be selecting stakeholder positions on the project steering committees for both uPortal and CAS. At the same time we will be asking you to select developer representatives to each of the committees. uPortal has two developer positions and CAS has one: Current uPortal Reps: Eric Dalquist Andrew Petro Current CAS Rep: Scott Battaglia These developer positions are not subject to term limits, and incumbents may serve successive terms. But we do ask each team to revisit their selections each year and make fresh recommendations. The way the process works is this: 1. Any developer may serve if selected 2. Only committers have votes; they are not required to belong to Member organizations 3. Discussion is open to all on the developer lists 4. Please initiate discussion on your list when the spirit moves you (This week would be a good time to start :-) 5. You may nominate others or yourself 6. We will need a decision on your selections by the end of the Jasig election process, which is July 17, 2009 7. Committee chairs should monitor these selections and report results back to the steering committees. 8. New terms officially begin on September 1, 2009 Questions? Please feel free to ask. Thank you! Jonathan -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: ape...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: lful...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] SVN Revision Renumbering
+1 Sounds like a good idea. Neither myself nor the projects I work on will have any problems with the change. Lennard - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Sent: Thursday, December 11, 2008 12:57:48 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] SVN Revision Renumbering We're getting closer to migrating some services to Jira Studio, with the move I'd like to take the opportunity to filter out a large number of empty revisions from our SVN repository. We have close to 28000 empty revisions in SVN, they are vestiges of the CVS2SVN import and a few failed imports that were filtered out along the way. No version history, JIRA issue links or file/folder properties would be lost. The end result is instead of being on commit 44480 or so we would be around 16500. Since people will need to check out projects new anyways because of the changed server name I don't think this would be a problem. I know both uPortal and CAS reference fixes by JIRA id and not rev number but I just wanted to run this by everyone here first. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Property files in up3
Eric discovered the related resource loader performance issue... he was running the profiler at the time:) The pearson system administrators both noticed and commented on the lack of easily accessible properties files and voiced their concerns about the move. I pointed out that they were easily accessible in the src, but they, in turn pointed out that waiting several minutes on a build for a property change was painful. Personally, I would prefer to see the property files readily available. If this is not to be a standard deployment, it would be nice if a production target were created which would make the properties accessible. -Lennard - Original Message - From: Cris J Holdorph [EMAIL PROTECTED] To: uportal-dev@lists.ja-sig.org Sent: Tuesday, July 29, 2008 5:01:28 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Property files in up3 Two of us (myself and Lennard Fuller) here at Unicon have both separately found out the hard way, that property files in up3 are packaged up in a jar file. I was wondering what the theory for that is. As both a developer and system deployer, I find this needlessly painful. It's a lot easier if the file is unarchived and can be modified directly, without having to unjar the files and remove the jar file first. Lennard, actually discovered that the jar file access was taking a fair amount of CPU time as well. Is there some benefit to the property files being in a jar file, that I'm overlooking. All I can see, at the moment are several downsides, and would like to know if we can switch back to non-jarred propety files. Also, I think it would be useful, if we could look into a facility similar to Sakai's sakai.properties file, where you can potentially override properties without having to modify the original file at all. Anyone who has had to maintain propeties on a per machine basis will know the value of having a 'machine specific' properties file, that overrides the defaults for the 'generic system'. Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [VOTE] Tuyhang Ly for uPortal committer
+1 Eric Dalquist wrote: I'd like to propose making Tuy a uPortal committer, she has provided several high-quality patches and enhancements to uPortal 3.0 both pre and post release and it would be good to have her committing these on her own. -Eric As a reminder votes need three positive votes with no negative votes to pass. If you vote -1 please include a detailed reason. The vote will remain open until at least 5/27. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [VOTE] Upcoming 3.0 release
+1 Eric Dalquist wrote: My current plan is to cut the uPortal 3.0.0-GA release this week (Wednesday or Thursday). There are only a few Jira issues remaining [1] and none of the fixes since RC3 have been major changes. [1] http://www.ja-sig.org/issues/secure/IssueNavigator.jspa?reset=truepid=10020resolution=-1fixfor=10550sorter/field=prioritysorter/order=DESC If you have an objection (-1 vote) please provide a few lines as to why. Thank you, -Eric -- Join your friends and colleagues at JA-SIG 2008 - Higher Education Solutions: The Community Source Way! April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uP3 persistence libraries
+1 We've used hibernate pretty extensively on a number of projects, both large and small, overall I've been very pleased with the results. You are likely already aware of this, but the Spring community no longer recommends using the HibernateTemplate and instead prefers a template-less approach since the original reasons for the creation/usage of the HibernateTemplate no longer exist. Here is an article on the subject. http://blog.interface21.com/main/2007/06/26/so-should-you-still-use-springs-hibernatetemplate-andor-jpatemplate/ Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Guest issue found in DLM for uPortal 2.6 patches, 2.6_GA, and 2.5.1 when using multiple portlets.
In my environment uPortal 2.5.3+ patches (notably UP-1040, UP-1816), removing the special treatment for a guest in the CPortletAdapter's generateKey method appears to do the trick, and the resulting guests do not appear to be sharing a session. I hesitate to call this a fix, but at present, with the actual production portlets I am using it gives every indication of being usable. Lennard Lennard Fuller wrote: Has anyone else seen this issue? Steps to reproduce: 1) Using uPortal configured for DLM, Login as the guest-lo user and add three portlets to the layout. I selected RSS Portlet, Test Portlet 1, Test Portlet 2 2) Bounce the portal (this is necessary in order to get your layout changes to appear) 3) Visit the guest page (do not login). Observed Behavior: Portlets render fine, in their appropriate 'boxes' 4) Begin to interact with one of the portlets, select a test to run in one of the test portlets or select a different rss feed. Observed Behavior: Frequently one portlet's content will be displayed in another's box. Which portlet's content displays in which box will continue to change randomly with each interaction. Sometimes ALL boxes will be filled with one portlets content, other times each portlet's content will be rendered... just in the wrong box. This issue appears to be common to all DLM guest users but does not occur if the user is logged in. Another oddity observed is that this issue does not appear to exist in ALM. The aforementioned behavior has been observed in uPortal 2.5.3.1, uPortal 2.6_GA, uPortal 2.6 patches (At revision 42618) and a uportal 2.5.3 environment with UP-1816 http://www.ja-sig.org/issues/browse/UP-1816 and UP-1040 http://www.ja-sig.org/issues/browse/UP-1040 patches applied. I've created a jira ticket for it: http://www.ja-sig.org/issues/browse/UP-1869. This is not quite the same issue that was reportedly fixed in UP-863. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Guest issue found in DLM for uPortal 2.6 patches, 2.6_GA, and 2.5.1 when using multiple portlets.
Has anyone else seen this issue? Steps to reproduce: 1) Using uPortal configured for DLM, Login as the guest-lo user and add three portlets to the layout. I selected RSS Portlet, Test Portlet 1, Test Portlet 2 2) Bounce the portal (this is necessary in order to get your layout changes to appear) 3) Visit the guest page (do not login). Observed Behavior: Portlets render fine, in their appropriate 'boxes' 4) Begin to interact with one of the portlets, select a test to run in one of the test portlets or select a different rss feed. Observed Behavior: Frequently one portlet's content will be displayed in another's box. Which portlet's content displays in which box will continue to change randomly with each interaction. Sometimes ALL boxes will be filled with one portlets content, other times each portlet's content will be rendered... just in the wrong box. This issue appears to be common to all DLM guest users but does not occur if the user is logged in. Another oddity observed is that this issue does not appear to exist in ALM. The aforementioned behavior has been observed in uPortal 2.5.3.1, uPortal 2.6_GA, uPortal 2.6 patches (At revision 42618) and a uportal 2.5.3 environment with UP-1816 http://www.ja-sig.org/issues/browse/UP-1816 and UP-1040 http://www.ja-sig.org/issues/browse/UP-1040 patches applied. I've created a jira ticket for it: http://www.ja-sig.org/issues/browse/UP-1869. This is not quite the same issue that was reportedly fixed in UP-863. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] PROPOSAL: change use_anchors property default to false in 2.6
+1 Cris J Holdorph wrote: I propose we turn this property to false by default in the 2.6 branch. This property has always caused a problem with Portlets and IE. It just doesn't seem like the default behavior out of the box should be 'broke'. If an institution likes the behavior they can still turn it back on. http://www.nabble.com/Re%3A-Spring-Porltet-MVC---IE6-Form-Submit-Problem-p13569657.html Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [uportal-user] uPortal Session Failures?
I've been following this thread for a while now, and for the life of me can not see why the portlet web applications that we have running in uPortal 2.5.3 (using Tomcat 5.5.23) have not suffered these types of errors. We have multiple web applications with multiple portlets, each portlet makes use of the portlet session. None of the aforementioned portlets seem to have exhibited the UP-1816 issue in either user acceptance testing or production (in use for nearly a year at this point). The only possible difference that occurs to me that *might* be related is that we have our tomcat connector configured with emptySessionPath=true. Even that seems to be something of a long shot. Cris J Holdorph wrote: I apologize if this is in the IRC log. two questions. 1) why does the pluto 1.1 driver (test portal) not exhibit the same problem? Do they do something similar to what your patch does for uPortal? Specifically breaking part of the servlet spec (even though it probably is ok to do so)? 2) Will this change work in other containers? I know that CalPoly uses WebSphere (or did at some point in the past) and Colorado uses Resin. And a bonus question... * Does Tomcat 6 implement this optional 'erata' part of the Servlet spec? That is if, someone spent enough time to get uPortal 2.6.0 running in Tomcat 6, are they unlikely to see the same problem? Cris J H Eric Dalquist wrote: There is a possible patch for this issue attached to the Jira case: http://www.ja-sig.org/issues/browse/UP-1816 This patch *_HAS NOT_* been extensively tested yet and makes some significant changes in the ChannelRender and related code. The Jira issue also has a link to yesterday's IRC log which I would recommend reading if you are interested in an in-depth discussion about the probably underlying issue causing the session bug. The high level overview is that due to uPortal's multi-threaded rendering model the Tomcat requestDispatcher is creating incorrectly wrapped HttpServletRequest objects to pass to the portlets for rendering. A more detailed overview follows, if there are questions about the patch please ask. Until an errata was recently filed in the servlet 2.4 spec it was against spec to allow multiple threads to access the request or response objects. The errata changed this so that it is no longer against spec but containers can optionally support multi-threaded access to these objects. With this wording it is not specifically a Tomcat bug, just an optional part of the spec that Tomcat does not implement. The patch involves having the ChannelRenderer.Worker class, which invokes rendering on a channel, create a wrapper around the HttpServletRequest specific for the thread that Worker is running in. The wrapper implements HttpServletRequest directly instead of extending HttpServletRequestWrapper to stop Tomcat from un-wrapping the wrapper. Passing objects back to the servlet container that are not either the original request object or extended from HttpServletRequestWrapper is also against the servlet spec, though breaking spec compliance in this area should fix the session problem and doesn't appear to cause other problems. The objects, specifically PortalControlStructures, which track the request and response through the rendering pipeline have also been modified to use ThreadLocals. This allows each rendering thread to have its own request and response objects as required by this patch. This patch is very closely based on code that UW-Madison has been running since going live in June 2006. It was not contributed back earlier due to both the significance of the changes in the rendering pipeline and the thought that the problem being addressed by the change was specific to a special case here at UW. I would encourage people experiencing the session problem and those who are familiar with the inner workings of the uPortal channel rendering code to try the patch and provide feedback. The patch was created against the 2.5-patches branch. Once some testing has been done on it confirming its viability I will create a patch for the 2.6-patches branch as well. -Eric Elliot Metsger wrote: Yup, I pulled HEAD of the 2-6-patches branch, and the buggy behavior still exists Parker Grimes wrote: Elliot, Yes we are using uPortal 2.6.0 GA with no custom patches. getMarkup() in CPortletAdapter is synchronized. -Parker On 9/9/07, Elliot Metsger [EMAIL PROTECTED] wrote: Hi Parker, Quick question: are you using uPortal 2.6.0 GA? Have you applied any custom patches? I'm curious if your CPortletAdapter's getMarkup() method is synchronized. Parker Grimes wrote: This is sounding very familiar to what we have been experiencing. We use uPortal 2.6.0 and the Spring Portlet MVC. -- View this message in context: http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 Sent from the uPortal - User mailing list archive at
Re: [uportal-dev] Requiring Jira issue ids in commit messages
I am definitely for requiring a jira number. + 1 Eric Dalquist wrote: Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
