Opa Fabricio, > Muito a sério mesmo, esse projeto tem 9 máquinas no Cluster, todas > máquinas de alto desempenho, com Alta Disponibilidade, mesmo no Zeo, > sem o software pago da Zope. :)))))
parece um case e tanto, não esqueçam de divulgar depois de concluído, afinal isso dá um ótimo crédito ao Zope/Plone e a vocês, claro. > Valeu pelas dicas, mas o furo foi um pouco mais em baixo. > > Tenho aula com o Sidnei na quinta de noite, e aproveitei e falei com ele. :) Hehehe, a pessoa certa, no lugar certo, na hora certa... difícil disso acontecer. Mais impressionante é que esse cara certo ainda não concluiu sua a graduação, um fenômeno! > Mechendo, vendo os logs e vendo a nossa estrutura acabamos descobrindo > que o problema é referencia cruzada entre Data.fs, como nós usamos um > Data.fs para o portal, e 2 Moint Points dentro, 1 para histórico e 1 > para material, houve, não sei como uma referencia entre arquivos destes > Moint Points. O Pack usa a classe serialize.py e la dentro > 'n'(Multi-database reference) é tratada como referencia fraca, e > ignorada, mas acaba estorando quando se dá um Pack. > E se eu der um Pack no Data.fs do material, vou ter um PosKeyError e > perco os objetos do Data.fs histórico. Eu li a thread do Sid com o J1m... incrível que isso está quebrado desde sempre! Incrível também como o problema se manifestou em dois lugares diferentes quase ao mesmo tempo, depois de tantos anos... > Já foi disparado um e-mail para zope-dev, o Sidnei e o Jim estão vendo > como tratar isso, talvez ampliando o Pack para que ele possa ser entre > Data.fs, ou melhorando o produto Mount Point, ou criando um patch de > correção para essas referencias cruzadas. É muito possível que o Sid corrija isso ainda no fim de semana, só para dar mais uma estucadinha no J1m... ;-) > O fsrecovery.py não faz nada. > O fsrefs.py acusa mais de 300 obj, quando o problema foi só em 4 obj. Uma possibilidade é que sejam 300 versões(!) anteriores dos tais 4 objetos, mas dicífil de afirmar... []'s -- Dorneles Treméa X3ng Web Technology
