Atualização: encontrei minha solução: link
DirectoryCacheLifetime definido como zero resolveu o problema.
Estou lidando com um problema e não consegui encontrar nenhuma postagem ou documentação que já tenha resolvido esse problema específico.
A configuração:
Esse problema está relacionado a um site altamente acessado, escrito no .NET 3.5 e executado no IIS7. O aplicativo utiliza um índice de pesquisa do Lucene via caminho UNC definido no Web.config do aplicativo. Esse caminho UNC é o mesmo em cada um dos 16 servidores da Web e todos acessam o mesmo índice nesse único local. O aplicativo é executado no modo clássico (vs integrado) e usa uma identidade e representação. A conta tem permissões suficientes. Os servidores da web são todos os servidores do Windows 2008 e o compartilhamento de arquivos de origem também é o servidor do Windows 2008 que executa o SQL Server 2008 também. Os servidores estão sempre em uma configuração de estação de trabalho, nunca um domínio e nenhum AD. Todos os servidores têm uma conta de usuário principal configurada de forma idêntica com permissões e senha idênticas.
A história:
Esta configuração tem funcionado bem durante anos sob algumas configurações. Recentemente, com servidores Web executando o Windows 2003 e IIS6 acessando esse compartilhamento de arquivo UNC remoto em um servidor Windows 2003 executando o SQL Server 2005. E mais recentemente com servidores Web executando o Windows 2008 e IIS7 acessando esse compartilhamento de arquivos UNC remoto no mesmo Windows 2003 com SQL apenas referido. O problema ocorre somente agora depois de ter movido esse compartilhamento UNC para esse novo servidor Windows 2008 com SQL.
O problema:
O site funciona bem atualmente e cada servidor da Web tem acesso ao índice e utiliza com êxito o índice como deveria. No entanto, periodicamente (entre 1 e 15 minutos com base na atividade e em um serviço cronometrado), o arquivo "segmentos" do Lucene é removido e substituído (ele é alterado). O arquivo atual, por ex. "segments_xyz" é substituído por "segments_zyx". Nem sempre isso ocorre, mas na maioria das vezes, o aplicativo procura o arquivo anterior, não o arquivo atual. Isso resulta em um FileNotFoundException e o erro .NET relatado é: System.IO.FileNotFoundException: não foi possível encontrar o arquivo '\ X.X.X.X \ Index \ 20101201 \ guid-x-x-x-x \ segments_zyx'. Isso dura de 1 a 3 segundos e ocorre em todos os servidores. Isso é reproduzível na medida em que posso acessar o site diretamente em um servidor, observar o arquivo a ser alterado e, quando isso acontece, posso atualizar a página e receber o erro por 1 a 3 segundos.
Alguns pontos e teorias:
Suspeitei que isso seja um problema de permissão, embora isso não pareça provável. Eu já exaurei as opções de configuração de permissão. Cheguei ao ponto de configurar o compartilhamento de arquivos com acesso público completo utilizando o grupo de contas de usuários Todos e a conta de identidade recebeu privilégios totais de administrador ao ser incluída no grupo Administradores. Eu ajustei as configurações de representação de autenticação do ASP.NET entre outras coisas.
Suspeitando de algum tipo de cache de compartilhamento de arquivos UNC Revisei as configurações de Cópia de Sombra (VSS) no servidor de compartilhamento de origem e examinei cada servidor da Web para garantir que não há versões anteriores, etc. também parece improvável uma causa para mim.
A execução do aplicativo no modo Integrado não é uma opção
Esse problema ocorre em todos os nossos 16 servidores da Web e parece que todos (ou a maioria) sofrem ao mesmo tempo pelas mesmas iterações de alteração de arquivo.
Para ficar bem claro, esse problema só se manifestou quando movi o compartilhamento do nosso servidor Windows 2003 w / SQL para o Windows 2008 w / SQL server. As configurações são tão idênticas quanto possível e não há nada especial sobre a configuração, é um compartilhamento de arquivos padrão simples com permissões comuns configuradas.
Concluí as reinicializações necessárias, reconfigurações, redefinições de serviços, etc.
Eu tentei alterar a configuração do caminho UNC para uma configuração de unidade mapeada, mas há problemas de aplicativo que impedem essa opção atualmente. Não sei se isso resolveria esse problema atual e preferiria não implementar isso como uma solução.
Esse problema causa milhares de erros por dia. Espero que alguém tenha algumas ideias? Eu serei eternamente grato por qualquer ajuda sobre isso!
Atualização: encontrei minha solução: link
DirectoryCacheLifetime definido como zero resolveu o problema.