Thank you, Desmond. I will try this on our test server and see. Where are the log.info() results displayed?
At 10:54 AM 2/15/2008, Desmond Elliott wrote: >I hypothesise that retrieving the ResourcePolicy for each of the 359 >Collections and then determining if a user is a member of the Group >associated with the Collection is why there is a long delay in >submissions from the MyDSpace interface. > >George could insert log.info() method calls into the SubmitServlet.java >file at line 306, and after line 309, and re-compile and re-deploy. >These calls would log the time of the start and the end of the operation >for users who are / are not administrators to attempt to help determine >if this is the reason for long delays. If this proves there is an >objective difference in the time then the log methods can be moved >closer to the end of the call tree to determine exactly where most >computation occurs. > >The SubmitServlet adds a Collection[] to the select-collection step of >the submission process [-1] line 308. > >This Collection[] is created through a call to the >Collection.findAuthorized(context) static method [0] line 1150. > >The findAuthorized() method calls the findAll() method, [0] line 273, >which returns a list of all Collections in the collection database table >which should not be an expensive operation since it queries the database >and retrieves 359 rows. > >A line contained inside the findAll() method block, line 285, determines >if the Collection object to be added to the Collection[] is cached in >memory. This should not be an expensive operation since the fromCache() >method determines if the Collection object is cached in a HashMap - >which offers O(1) access, [1] line 289. > >The returned Collection[] is then examined, for each Collection object, >to determine if the current user has authorisation to write to that >Collection. The AuthorizeManager class method authorizeBooleanAction() >[2] line 217, calls authorizeAction() [2] line 131, calls authorize() >[2] line 258. > >The authorize() method in AuthorizeManager retrieves a ResourcePolicy >and determines if the user is authorized as per the ResourcePolicy to >have access to the collection. > >Users who are admins do have have to step through the ResourcePolicy >stage. George states that he suffers a delay when trying to submit from >the MyDSpace page but that it is a shorter delay than what others are >experiencing - 30s -> 60s vs 60s -> 300s. The only stage in the process >I can determine where there is a difference between Admins and Users is >at this point. > >Having to retrieve the ResourcePolicy for each of the 359 collection >objects and determine if a user is part of that ResourcePolicy could be >the choke point. > >I appreciate any thoughts on my analysis of what could be causing the >problem that George is experiencing. > >[-1] >http://dspace.svn.sourceforge.net/viewvc/dspace/branches/dspace-1_4_x/dspace/src/org/dspace/app/webui/servlet/SubmitServlet.java?view=markup >[0] >http://dspace.svn.sourceforge.net/viewvc/dspace/branches/dspace-1_4_x/dspace/src/org/dspace/content/Collection.java?view=markup >[1] >http://dspace.svn.sourceforge.net/viewvc/dspace/branches/dspace-1_4_x/dspace/src/org/dspace/core/Context.java?view=markup >[2] >http://dspace.svn.sourceforge.net/viewvc/dspace/branches/dspace-1_4_x/dspace/src/org/dspace/authorize/AuthorizeManager.java?view=markup > >-- >Desmond Elliott | Hewlett-Packard Limited registered Office: >Research Associate | Cain Road, >HP Labs | Bracknell, >Bristol, UK | Berks >+44 117 312 8526 | RG12 1HN. >[EMAIL PROTECTED] | Registered No: 690597 England > >The contents of this message and any attachments to it are >confidential and may be legally privileged. If you have received this >message in error, you should delete it from your system immediately >and advise the sender. To any recipient of this message within HP, >unless otherwise stated you should consider this message and >attachments as "HP CONFIDENTIAL". > > >George Kozak wrote: > > > Hi... > > Back in January, I wrote to the list about a problem we are having > > (at Cornell) with DSpace after we migrated from v. 1.3.2 to v. 1.4.2. > > > > Basically, if someone logs into DSpace by clicking on "My DSpace" and > > then clicks on the "Start a New Submission" button, there can be a > > delay from anywhere from 30 seconds to several minutes before the > > "Submit: Choose Collection" screen appears. Clicking on the "Start a > > New Submission" button in "My DSpace" can run the CPU usage up over > > 40%. This doesn't happen if one goes directly to the Collection to > > which he or she is authorized to submit and clicks on the "Submit to > > this Collection" button there. > > > > Randall Floyd of Indiana University thought that this might be a > > cleanup program in PostGreSQL, but I run vaccumdb nightly and do a > > re-index daily. > > > > Claudia Jurgen of TU Dortmund suggested that this may be the result > > of a complicated Community/SubCommunity/Collection structure (we have > > 118 Communities/Sub-Communities and 359 Collections). > > > > I have been looking at alternatives. I have put a message on the My > > DSpace main page telling people to go to the collection they want to > > submit to and click on the "Submit to this Collection" button there, > > but (as you can imagine) most people aren't doing that, and I am > > beginning to receive complaints from our users. > > > > Is anyone else having this problem? > > > > Does anyone have any ideas as to what I can do to make this a little > > bit better? Thank you! > > > > (PS. I am running a SunFire-480-R with 4GB of memory and 8GB of swap > > space. I am running PostGreSQL 7.2.3 and Tomcat 4.0.6.) > > > > *************************** > > George Kozak > > Digital Library Specialist > > Library Systems > > 501 Olin Library > > Cornell University > > 607-255-8924 > > *************************** > > [EMAIL PROTECTED] > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > DSpace-tech mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >DSpace-tech mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/dspace-tech *************************** George Kozak Coordinator Web Development and Management Digital Media Group 501 Olin Library Cornell University 607-255-8924 *************************** [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
