Hi Luca Updates to the resource index are in fact cached in a buffer so that the updates don't potentially slow down Fedora API operations (so the updates continue in the background).
Maybe this is the cause in this case; PROAI was running its query before the changes had been committed? It looks like when you later ran the query on Mulgara the updates had been committed by that point. There is a parameter to control this in fedora.fcfg. If you locate the section <module role="org.fcrepo.server.resourceIndex" ... > And change the parameter ... <param name="syncUpdates" value="false"> ... to "true" and restart Fedora Does that make a difference? Regards Steve -----Original Message----- From: Luca Lelli [mailto:l.le...@inera.it] Sent: 04 February 2011 15:48 To: Support and info exchange list for Fedora users. Subject: Re: [fcrepo-user] problems with proai.propertiesparameters configuration? Hi all, we have done a deeper test. At the beginning we had 100 objects in Fedora with state 'A'. Then we have deleted these objects i.e. set to state 'D', and this events have been correctly recorded in PROAI cache. After that we have re-activated these objects to state 'A'. Analyzing the DEBUG log of PROAI we have seen that PROAI has done a RISearch query to Mulgara in order to retrieve the modified objects after T1 and before T2. The log output has shown a sparql XML containing 83 objects. These objects have been correctly recorded in cache by PROAI. So 17 objects were missing from Mulgara result. We had controlled the modification date of these objects and these were between T1 and T2. The problem seems to be in Mulgara that does not return the correct numer of modified objects. After about one hour we have done the same Risearch query to Mulgara with Web Browser and we have obtained the correct result. Thanks in advance and best regards, Luca 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? > >> 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 > >> 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. > > 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 -------------------------- ---------------------------------------------------------------------------- -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
