Hello Andrea, I have a problem with the DSPACE and the OAI-PHM, similar to 
the one of Demmis, it is not possible to update the records in the OAI 
../oai/request?verb=ListSets, It shows me the old configuration and old 
records (33) Now they are 97. As I show you the output of the command:
# curl 'http://localhost:8080/solr/oai/select?q=*:*&indent=true&rows=0'
<?xml version="1.0" encoding="UTF-8"?>
<response>

<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="q">*:*</str>
    <str name="indent">true</str>
    <str name="rows">0</str>
  </lst>
</lst>
<result name="response" numFound="97" start="0">
</result>
</response>


A help please,
Thanks

El lunes, 8 de febrero de 2016, 23:15:17 (UTC-5), Andrea Schweer escribió:
>
> Hi,
>
> I'm really not sure what's going on. Your log shows DSpace posting 
> information to Solr, which is what I'd expect. Have you checked the 
> permissions of the Solr directory tree? It needs to be owned by the same 
> user that Tomcat runs under ([dspace]/solr/oai and subdirectories).
>
> As a last resort, you could manually delete everything from that solr 
> index, then run another import. It shouldn't really do anything different 
> compared to clean-cache, but you never know. 
>
> If you run eg
> curl 'http://localhost:8080/solr/oai/select?q=*:*&indent=true&rows=0'
> then you'll see how many items the OAI solr core currently knows about -- 
> look for numFound. numFound should be equal to the number of items (this 
> might include non-public items and deleted items) after running import.
>
> You can run
> curl --globoff http://localhost:8080/solr/oai/update -H "Content-Type: 
> text/xml" --data-binary '<delete><query>*:*</query></delete>'
> followed by
> curl --globoff 'http://localhost:8080/solr/oai/update?commit=true'
> to force-delete everything in that solr index (you might want to try this 
> on a test server first).
>
> numFound in the first query above should then be 0. Run clean-cache and 
> access your web interface *without* running the import command -- it too 
> should tell you that there are 0 identifiers. If it still claims that there 
> are items, you may have a web cache layer in front of your repository or 
> something? If you do get 0 identifiers via the web interface after the 
> delete, run the import command and check again. Hopefully you'll then see 
> exactly those items you're expecting to see.
>
> Just a very final comment -- what are you looking at in the OAI interface? 
> I just followed the links in your initial e-mail again and the OAI 
> interface now shows 30 records/identifiers, the same number of items as 
> shown in JSPUI. So perhaps your earlier steps actually did work and you're 
> just looking at an out-of-date web page for some reason?
>
> cheers,
> Andrea
>
> On 09/02/16 16:48, Demis Estabridis wrote:
>
> Hi Andrea, 
>
> Thanks again for your answer.
> I can confirm that we're using SOLR as database source for OAI.
>
> We run again the suggested commands and we had no errors on the logs but 
> no new result. Nothing changed. 
>
> /opt/dspace/bin/dspace oai clean-cache
> /opt/dspace/bin/dspace oai import –c
>
> Please, find here the logs with debug mode on.
> We did it with the tomcat user:
>
> 2016-02-08 22:24:29,115 INFO  org.dspace.core.ConfigurationManager @ 
> Loading from classloader: file:/opt/dspace/config/dspace.cfg
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ Using 
> dspace provided log configuration (log.init.config)
> 2016-02-08 22:24:29,148 INFO  org.dspace.core.ConfigurationManager @ 
> Loading: /opt/dspace/config/log4j.properties
> 2016-02-08 22:24:33,149 DEBUG net.sf.ehcache.config.ConfigurationFactory @ 
> Configuring ehcache from InputStream
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xmlns:xsi
> 2016-02-08 22:24:33,271 DEBUG net.sf.ehcache.config.BeanHandler @ Ignoring 
> ehcache attribute xsi:noNamespaceSchemaLocation
> 2016-02-08 22:24:33,280 DEBUG net.sf.ehcache.config.DiskStoreConfiguration 
> @ Disk Store Path: /tmp
> 2016-02-08 22:24:33,306 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheManagerEventListenerFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No BootstrapCacheLoaderFactory class specified. Skipping...
> 2016-02-08 22:24:33,346 DEBUG net.sf.ehcache.config.ConfigurationHelper @ 
> No CacheExceptionHandlerFactory class specified. Skipping...
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS is 'PostgreSQL'
> 2016-02-08 22:24:35,926 INFO  org.dspace.storage.rdbms.DatabaseManager @ 
> DBMS driver version is '9.4.5'
> 2016-02-08 22:24:35,966 INFO  org.dspace.storage.rdbms.DatabaseUtils @ 
> Loading Flyway DB migrations from: filesystem:/opt/dspace/etc/postgres, 
> classpath:org.dspace.storage.rdbms.sqlmigration.postgres, 
> classpath:org.dspace.storage.rdbms.migration
> 2016-02-08 22:24:35,999 INFO 
>  org.flywaydb.core.internal.dbsupport.DbSupportFactory @ Database: 
> jdbc:postgresql://localhost:5432/dspace (PostgreSQL 9.4)
> 2016-02-08 22:24:36,005 DEBUG org.flywaydb.core.Flyway @ DDL Transactions 
> Supported: true
> 2016-02-08 22:24:36,018 DEBUG org.flywaydb.core.Flyway @ Schema: public
>
> Any ideas what could be wrong here?
> Is there any way to change this manually? It's very urgent to get this 
> fixed for us.
>
>
>
> *Demis Estabridis *Director de TI
> *UTEC*
>
> *Universidad de Ingeniería & Tecnología*
> * › *T: (511) 230 5000
>  *› *Jr. Medrano Silva 165, Barranco
>  ›  <http://www.utec.edu.pe/>*www.utec.edu.pe <http://www.utec.edu.pe>*
>
>
> 2016-02-08 22:02 GMT-05:00 Andrea Schweer <sch...@waikato.ac.nz 
> <javascript:>>:
>
>> Hi,
>>
>> On 09/02/16 15:45, Demis Estabridis wrote:
>>
>> Hi Andrea, 
>>
>> Thanks for your quick response.
>> In fact, we have tried doing this:
>>
>> [8/2/16 21:43] Erick Benites (eben...@tecsup.edu.pe <javascript:>):sudo 
>> rm –R -f /opt/dspace/var/oai/requests/*
>> sudo /opt/dspace/bin/dspace oai clean-cache
>> sudo /opt/dspace/bin/dspace oai import –c
>>
>>
>> That looks good in general, but a few comments:
>>
>>    - You don't need to delete the directory yourself, the clean-cache 
>>    command should sort this out for you 
>>    - Don't run any dspace command using sudo (=root). You *must* run 
>>    these commands as the same user that Tomcat runs under, which will most 
>>    likely be "tomcat" or "dspace" depending on your set-up. If you run these 
>>    commands as root, chances are that the permissions of any 
>> directories/files 
>>    created by the command will be wrong and will cause future operations to 
>>    fail. 
>>    - I personally run import before clean-cache, just on the off-chance 
>>    that someone accesses an OAI page (and thus causes the cached response to 
>>    be re-generated) in between. This is probably no longer necessary since 
>>    import now also runs clean-cache (I believe), but I'm not sure exactly 
>> when 
>>    this changed.
>>    
>>
>> But we don't see any change on  /oai/request records. Our Jspui shows 30 
>> docs, and we have 59 on the OAI interface.
>>
>>
>> That's odd. Just in case, check the DSpace log file for any error 
>> messages around when you're running clean-cache / import.
>>
>> Could you verify that you're indeed using the solr data source for OAI? 
>> In [dspace]/config/modules/xoai.cfg file, the "storage" parameter 
>> configures which data source is used (database vs solr). solr is now the 
>> default. If yours is set to "database", you'll need to run slightly 
>> different commands as given in this section here: 
>> https://wiki.duraspace.org/display/DSDOC5x/OAI+2.0+Server#OAI2.0Server-OAIManager%28DatabaseDataSource%29
>>
>> *Syntax*
>>
>> [dspace]/bin/dspace oai <action> [parameters]
>>
>> *Actions*
>>
>>    - clean-cache  *Cleans the OAI cache* 
>>    - compile-items  *Compiles DSpace items* 
>>    - erase-compiled-items  *Erases all DSpace compiled items* 
>>
>>
>> cheers,
>> Andrea
>>
>> -- 
>> Dr Andrea Schweer
>> Lead Software Developer, ITS Information Systems
>> The University of Waikato, Hamilton, New Zealand
>> +64-7-837 9120
>>
>>
>
> La información contenida en este e-mail y sus anexos es confidencial, 
> privilegiada y está dirigida exclusivamente a su destinatario, en 
> consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
> destinatario original, no deberá examinar, usar, copiar o distribuir este 
> mensaje o la información que contiene. Si lo recibe por error, por favor 
> reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
> uso total o parcial no autorizada de este mensaje está estrictamente 
> prohibida y sancionada por ley. 
>
>
> -- 
> Dr Andrea Schweer
> Lead Software Developer, ITS Information Systems
> The University of Waikato, Hamilton, New Zealand
> +64-7-837 9120
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Reply via email to