DSpace 6.3 - inserção de itens interrompida

Imagino que pouca gente ainda continue usando a versão 6.3, mas ainda não foi possível atualizar para alguma das mais recentes. Enquanto isso, é preciso manter o repositório funcionando.
O problema foi detetado quando se tentou exibir um item recém inserido e aconteceu um “Erro interno de sistema”. Estou usando jspui, mas nem no log, nem na página que mostra o erro apareceu o stack trace. Só consegui alguma informação quando lembrei que tenho funcionando (com a interface básica) o xmlui. Aí consegui o stack trace e, depois de muita busca, verifiquei que o item que provoca o erro foi parcialmente inserido. Ele tem handle e uuid, ele aparece na tabela collection2item (apenas uma vez), ele tem todo o conjunto de metadados inserido, mas na tabela item aparecem dois problemas: o campo in_archive está como false e o campo owning_collection está nulo (é esse campo que provoca o system error, com o NullPointerException).

Se tivesse ocorrido apenas uma vez, já seria um problema, mas já há, pelo menos, um outro caso.

É fácil corrigir a situação, modificando o in_archive para true e colocando a coleção a que está associado como owning_collection (o que é correto), mas eu preciso saber a causa, para evitar que aconteça.

A minha pergunta é: alguém já passou por isso e pode me dar alguma ajuda?

Obrigado.

1 curtida

Se o in_archive fica false e owning_collection fica NULL, geralmente o item não chegou a ser “publicado” (etapa final do submit/workflow), mesmo com handle e metadados já criados. Isso costuma ocorrer por exceção em algum passo do submission/workflow, por consumer (indexação, DOI/Handle, customizações) ou por interrupção do Tomcat ou da conexão com o PostgreSQL no momento do commit. Como você viu que JSPUI nem sempre mostra stack trace, o caminho é verificar o [dspace]/log/dspace.log e, se estiver usando Tomcat, também os logs (catalina.out ou localhost.*). Se ainda não aparecer nada, aumente temporariamente o log para debug em org.dspace.submit e org.dspace.workflow e tente reproduzir o problema, normalmente a causa real aparece ai

Obrigado por sua resposta.
Eu não entendi bem como aumentar o log para debug em org.dspace.submit e org.dspace.workflow. Isso é para a versão 6.3?

Eu encontrei na documentação oficial do Dspace 6 (Directories and Files - DSpace 6.x Documentation - LYRASIS Wiki) a seguinte explicação sobre a linha do arquivo [dspace]/config/log4j.properties:

log4j.logger.org.dspace=INFO,A1:

“Essa linha controla o nível de registro de logs. Normalmente, elas devem ser definidas como INFO, mas se você precisar ver mais informações nos logs, defina-as como DEBUG e reinicie o servidor web.”

Olhei aqui e no DSpace 6.3 em log4j.properties, isso aparece da seguinte forma:

loglevel.dspace=INFO
log4j.logger.org.dspace=${loglevel.dspace}, A1

Em loglevel.dspace=INFO se você alterar para DEBUG, coloca todo o org.dspace.* em DEBUG, isso gera bastante log, então não é ideal deixar por muito tempo (use só para descobrir o erro, pois pode lotar o disco)

A outra opção é habilitar DEBUG apenas para submit/workflow, mantendo loglevel.dspace=INFO, adicionando no mesmo arquivo, seria algo assim conforme os outros exemplos no arquivo, mas é preciso testar:

log4j.logger.org.dspace.submit=DEBUG, A1
log4j.additivity.org.dspace.submit=false

log4j.logger.org.dspace.workflow=DEBUG, A1
log4j.additivity.org.dspace.workflow=false

Só lembrando que é sempre recomentado backup antes de qualquer teste, e se possível utilize o ambiente de homologação e não o de produção.

1 curtida

Olá, Mirele.
Demorei a voltar aqui, mas cheguei.
Vou tentar.
Obrigado.