[EP-tech] Very slow access, File not found, Error Generating views

David R Newman drn at ecs.soton.ac.uk
Wed Jan 31 01:59:02 GMT 2018

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 
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.


David Newman

On 31/01/2018 00:54, Eliseo Gatchalian wrote:
> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20180131/7981f1ad/attachment-0001.html 

More information about the Eprints-tech mailing list