Hi Ellis,

If you have a user who as a large number of EPrint records associated with them (maybe their account ID was used during a mass import), then when that user logs in, the first page they will be taken to lists their EPrint records, this can be quite slow with hundreds and certainly thousands of records.  This is often even slower if you are also using the MEPrints plugin, which tries to load various stats when it logs you in and takes you to your profile page.  Is it just when you login or navigating about as well, say editing 1 particular EPrint record?  The only things I can think that may cause all pages to be slow to load is either if there is something odd in the user record itself or that something that calls off to a remote service with the username and for some reason it has issues with that particular username.  For the former, I have never seen one user being a lot slower than all others, so I cannot suggest what to look for in the user record.  For the latter, this would have to be some bespoke feature added to your repository, as there is nothing like this that EPrints does by defaullt.

If an item is not in the live archive it will give a 404 error like I can see on the link you provided.  I assume you have probably checked this.  If not, check at https://researcharchive.wintec.ac.nz/cgi/users/home?screen=EPrint%3A%3AView&eprintid=3637 and look under the Details tab for the Status field.  By default this should show "Published" (or something similar if the phrase has been changed) if the item is in the live archive and therefore should not give a 404.  There may be other reasons for this not being present but it difficult to know what this might be.  One thing you could try, is going to the Action tab on the link I provided above and moving to review and then moving back to the repository, this may clear something that has got wrongly cached.

For the EPScript error, abstract pages (i.e. the views being generated) are static and when the generate_views script is being running there is no $current_user.  I would advise removing any use of $current_user in citations (i.e. in this case cfg/citations/eprint/default.xml from your archive's directory).  $current_user is really only intended to be used in workflows (e.g. cfg/workflows/eprint/default.xml) where there will be being used by a logged in user.  This may also explain why you are getting a 404 for the record your reported, as the abstract page cannot be generated, due to this EPScript error.

Regards

David Newman

Hi,

 

I’m hoping if anyone can provide me guidance on how to fix the following issues:

 

1.       Very slow accessing EPrints when a particular user is logged in.  Other users are ok.

-          I’ve checked the following:  server space still 3.5GB left, network connections are ok since other user login are fast.  I’ve also restarted apache, but same issue with the users

2.       Getting a 404 error for user in issue#1 when accessing some of his items.

-          I’ve checked the eprint table and I can see the record for eprintid 3637 is there, but when we go to http://researcharchive.wintec.ac.nz/3637/, it is saying 404 File not Found.

3.       When generating views, I’m getting:

“EPScript error:  Script in citation eprint/default: can’t get a property {usertype from undefined value at character 14

  $current_user{usertype} = ‘editor’

                                ^ here at /opt/eprints3/bin/../perl_lib/EPrints/Script.pm line 162.”

 

 

I’m not sure if the above issues are all linked together or they are separate issues on their own.  Any help to fix the above issues is greatly appreciated.

 

Thanks!

 

 

Best regards,

Ellis

---

This electronic mail transmission is intended for the named recipients only. It may contain private and confidential information. If this has come to you in error you must take no action based upon it, nor must you copy it or show it to anyone; please telephone or email the sender at Wintec immediately and return the original email. We cannot accept any liability for any loss or damage sustained as a result of software viruses. It is your responsibility to carry out such virus checking as is necessary before opening any attachment which may be included with this message.

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/