Re: [fcrepo-user] Fedora resource Index query goes in timeout

[Luca Lelli]

Il 07/12/2012 21.07, Rastislav Hudak ha scritto: Hi all, we have the same problem. The query took 2.5 hours and then crushed on transaction timeout (I've checked and the timeout is set to one week by default so something is wrong here). But there's still the question why the query actually takes so long?? We didn't solve this but now we switched the auto update off and we are filling the database manually and then reload oaiprovider to pick up the rcQueue entries and update the cache :( Also, oaiprovider sometimes creates like 250k files, from which most of them are the same files over and over again. Sometimes it even crushes because it uses all the inodes. We have a script which checks this and then creates symlinks :( I thought it's just our problem. We are using RHEL6, standalone Mulgara and latest oaiprovider. My guess is that there might be something wrong with how the time (can explain the exception + time is also used to create paths for cache files). Regards, Rasta Hi Rasta, thanks for your answer. Some questions: What version Fedora are you using? And what version of Mulgara standalone are you using? Have you succeded in integrate Fedora with a version of Mulgara (standalone mode) subsequent that integrated in Fedora? How many objects/datastreamsa do you have in your Fedora repository? So i imagine that you have done a procedure which periodically fills PROAI database and reloads PROAI to complete caching. Please, may you tells us something more about that procedure? Thanks for your informations Luca On 7 December 2012 19:32, Luca Lelli <l.le...@inera.it> wrote: Hi all, we have a Fedora installation 3.4.2 with Mulgara embedded. It is loaded with about seventy thousands of objects with various datastreams. When PROAI makes its periodic query to update its data using itql with time ranges (before, after), the query does not answer and results in timeout (also more than one hour). We have tried the same query also in the online form with the same results. There is much log  but only of info level (no errors). But if we avoid to use the time limits the response is ok and fast. This is an eaxmple of query done by PROAI, which results in timeout:  select $item $itemID $date $state   from   <rmi://localhost/fedora#ri>   where  $item           <http://www.openarchives.org/OAI/2.0/itemID> $itemID   and    $item     <info:fedora/fedora-system:def/model#state> $state   and $item <info:fedora/fedora-system:def/view#disseminates> $diss   and $diss <info:fedora/fedora-system:def/view#disseminationType>  <info:fedora/*/pico>   and    $item     <info:fedora/fedora-system:def/view#lastModifiedDate> $date   and    $date           <http://mulgara.org/mulgara#after>  '2012-11-03T08:53:48.559Z'^^<http://www.w3.org/2001/XMLSchema#dateTime> in  <rmi://localhost/fedora#xsd>   and    $date           <http://mulgara.org/mulgara#before>  '2012-11-04T08:53:48.559Z'^^<http://www.w3.org/2001/XMLSchema#dateTime> in  <rmi://localhost/fedora#xsd> This is an eaxmple of query which is ok: select $item $itemID $date $state  from   <rmi://localhost/fedora#ri>  where  $item           <http://www.openarchives.org/OAI/2.0/itemID> $itemID  and    $item     <info:fedora/fedora-system:def/model#state> $state  and $item <info:fedora/fedora-system:def/view#disseminates> $diss  and $diss <info:fedora/fedora-system:def/view#disseminationType> <info:fedora/*/pico> and $item <info:fedora/fedora-system:def/view#lastModifiedDate> $date order  by $itemID asc We have seen in forum that similar problems where present in previous versions of Fedora, but the problems seem almost equal (for example Fedora-commons-users] Fedora Resource Index Query Service veryslow). Thanks for every response, Luca ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.2221 / Database dei virus: 2634/5442 - Data di rilascio: 06/12/2012 -- Luca Lelli -------------------------- INERA srl http://www.inera.it Via Mazzini 138 56125 Pisa Italy tel: +39 050 9911815 fax: +39 050 9911830 email: l.le...@inera.it --------------------------

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users