Closed GoogleCodeExporter closed 9 years ago
Estive a ver com o Carlos e o mesmo problema ocorre para outro recurso:
http://dev.epimarketplace.net/resource/empid%3A107
Segundo a explicação, o problema poderá estar no recurso em si. Já que há
um elemento em:generalDescription que contem um ficheiro e que deveria estar
num datastream específico. O que pode estar a fazer com que a passagem de
dados interna (entre webservices, drupal, fedora) demore e faça com que o
proxy termine a ligação e dê a resposta obtida.
A solução para isto poderá passar pela edição do recurso no fedoraCommons?
Original comment by graca.pa...@gmail.com
on 21 Dec 2011 at 5:22
Boas,
Paulo, ontem quando falámos sobre isso nem pensei que isso estivesse a dar
erro. Mas sim, a solução passa por eliminar o(s) recurso(s) que se encontrem
nesse estado irregular directamente no FedoraCommons ou alternativamente criar
novas streams associadas a esses mesmos recursos que iriam alojar os dados em
conflito.
Original comment by stinkle....@gmail.com
on 23 Dec 2011 at 2:06
Consigo fazer fetch e rawfetch ao recurso 46 e 107, o fetch (completo) demora
algum tempo porque o datastream de dados é bastante grande, mas não me parece
haver um problema de serviços. O rawfetch do datastream de metadados é mais
rapido.
Que ws usam na pagina /resource/ o fetch ou rawfetch?
De qualquer forma o problema parece ser do lado do servidor drupal que não
espera tempo suficiente. Alguma configuração do apache, talvez?
Original comment by eKzam...@gmail.com
on 27 Dec 2011 at 2:44
Quando acedo à pagina http://v2.epimarketplace.net/resource/empid%3A46 recebo
3 pedidos nos ws:
1- /rawfetch/pid/empid:46/datastream/EM
2- /fetch/pid/empid:46
3- /annotation/list/pid/empid:46
O 1º acede aos metadados, o 3º aos comentários, o 2º não percebo porque é
chamado, parece-me desnecessário e pode ser a origem do problema.
Original comment by eKzam...@gmail.com
on 27 Dec 2011 at 4:10
Estive a ver e acho que, para os coment�rios, est� a ser feito um load do
recurso.
Se este passo � mesmo necess�rio, a solu��o ter� que passar por fazer cache
no lado do Drupal.
Para os WS, talvez seja relevante estudarmos o Varnish. Permite guardar
cache de pedidos HTTP.
Original comment by graca.pa...@gmail.com
on 27 Dec 2011 at 6:40
O processo de obter o recurso foi completamente refeito.
Neste momento apenas se está a usar o webservice- rawfetch em detrimento do
fecth que obtém todo o recurso.
Em relação aos comentários, o recurso estava a ser novamente carregado,
atualmente usa-se apenas o pid para obter os comentários.
Exemplo:
http://v2.epimarketplace.net/resource/empid%3A4600
Original comment by graca.pa...@gmail.com
on 10 Jan 2012 at 2:21
Verificado
Original comment by graca.pa...@gmail.com
on 24 Jan 2012 at 2:14
Original issue reported on code.google.com by
graca.pa...@gmail.com
on 21 Dec 2011 at 5:11