Il 02/02/2011 18.54, Chris Wilper ha scritto: > Hi Luca, > > On Tue, Feb 1, 2011 at 1:46 PM, Luca Lelli<l.le...@inera.it> wrote: >> Hi, >> >> in a project we are using Fedora Commons 3.3 with PROAI for providing >> data to be harvested. >> We have seen that in some situations the cache of PROAI is not >> syncronized with Fedora Repository: i.e. some Fedora objetcs in PROAI >> cache are not present or if present are not aligned with the related >> Fedora objects. >> This seems to be more probable when some Fedora objects >> which are in state D (deleted) are again activated > So, sometimes you observe a discrepancy in other cases (besides when > an object goes from "D" back to "A"). Can you elaborate on the > differences you observe in those cases? At a first sight there are no apparent differences. >> i.e. the object >> state is modified to 'A'. The modification date of Fedora Object is >> correctly modified. But the PROAI cache signals always deleted. > Ok, this particular case should be enough to try to reproduce. I've > created an issue for it here, for tracking: > > https://jira.duraspace.org/browse/FCREPO-857 thanks >> Peharps thre are some issues with proai.properties parameters >> configuration? E.g. we are using proai.driverPollSeconds = 600 and the >> other Back-End Update Behavior parameters are left with default values >> (proai.maxWorkers = 5, proai.maxWorkBatchSize = 10, >> proai.maxFailedRetries = 3, proai.maxCommitQueueSize = 120, >> proai.maxRecordsPerTransaction = 60, proai.driverPollingEnabled = true). > It doesn't seem like anything about your configuration should be > causing these discrepancies, but it's good to know the config you're > using for the purpose of trying to reproduce the problem(s) you've > observed. One parameter we modified respect to the default value (120) is proai.driverPollSeconds which we set to 600 (sec). This because in our application may happen that in certain situations many Fedora objects are modified in a short interval: we thought that PROAI was not able to update in cache all records retrieved from Mulgara in a polling query, before the next query (always from PROAI to Mulgara) has been done. So because the cache update is done between polling cache time intervals the objects updated in the first interval but not processed in cache are for ever lost for PROAI cache. So our idea was to extend the proai.driverPollSeconds e.g. to 6000 (sec). May this be a good idea? Other people have had the same problem?
Thanks, Luca > Thanks, > Chris > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users -- 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 -------------------------- ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
