J'ai une fonction d'indexation nommée "Exécuter ()" à l'aide de l'indexwriter pour indexer le contenu de mon site. Cela fonctionne bien si je l'ai simplement appelé à partir d'une page Web, mais j'ai échoué lorsque je l'ai en tant que paramètre délégué dans System.threading.thread. Étrangement, cela fonctionne toujours sur ma machine de développement locale, elle ne manque que lorsque je télécharge un hôte partagé.
Ceci est le message d'erreur que j'ai reçu
"verrouillage obtenu chronométré: Erreur SimpleFsLock ...."
ci-dessous est le code défaillant (mais ne fait que tomber sur un hôte partagé. ) ci-dessous est le code qui fonctionne (fonctionne à la fois sur ma machine locale et sur l'hôte partagé) maintenant Certains personnes ont déclaré que cela pourrait être une mauvaise gauche de la session de débogage précédente, alors avant d'instancié l'index d'index, j'ai fait et devinez quoi? Mon journal dit, il n'est pas verrouillé. Alors maintenant, je suis sûr que c'est causé par le système.Trhead.threading, mais je n'ai aucune idée de la manière de le réparer. merci
4 Réponses :
Probablement le pire pour essayer de répondre à cela puisque je n'ai pas utilisé Lucene / hébergement partagé, mais SimpleFslock sonne comme s'il verrouille le fichier d'index Lucene à l'aide d'un fichier de verrouillage explicite sur le système de fichiers (pas tout à fait la même chose que le verrouillage en filetage). Je dirais vérifier pour vous assurer que vous avez configuré les chemins de fichiers appropriés et que les autorisations de fichier sont correctement définies.
sinon, j'espère que quelqu'un plus familier avec Lucene.net peut répondre.
Merci kevin. Les chemins de fichier sont corrects car si je n'exécutez simplement pas la fonction en n'impliquant pas le filetage, tout fonctionne comme prévu, des index sont en cours de création et je suis en mesure de rechercher tout le contenu. Dès que je passe la fonction dans le constructeur de fil (), il bombe. PS: Merci de m'avoir aidé sur le formatage :)
Vérifiez que sur l'hôte partagé, le thread a les mêmes autorisations au dossier d'index que vous le faites sur la machine de développement / hôte partagé.
update: Vous pouvez trouver ce que Vous pourriez trouver Cet article utile. principal le thread est en cours d'exécution en interrogeant la propriété CORRECTPRINCIPAL . Bien que ce soit une propriété en lecture-écriture, vous ne pouvez pas disposer des autorisations pour définir cette propriété dans votre environnement hôte partagé.
Hey Vinay, comment puis-je vérifier si un fil a la même permission que moi?
Je crois que le problème est avec un fichier de verrouillage en écriture dans le répertoire de l'index de Lucene. Allez énumérer les fichiers du répertoire. Dans Java Lucene, vous auriez vu un fichier nommé wreck.lock dans le répertoire index, Ce qui signifie que l'index n'était pas correctement fermé la dernière fois (peut-être un processus a été arrêté brusquement). À Lucene.net, recherchez un fichier vide similaire. Je crois que le même mécanisme sera utilisé à Lucene.net. Essayez de trouver ce fichier, effacez-le et redémarrez Lucene.net.
Merci yuval. Je viens de courir un script et il imprime des segments.gen segments_6 _1.cfs c'est tout. Le détail du message d'erreur indique en effet le problème avec "write.lock" dans mon répertoire d'indexation. Cependant, comme le résultat du script présenté ci-dessus, aucun fichier "wreck.lock" n'existe.
Merci à tout le monde et surtout à Vinay de me diriger dans la bonne direction. Après beaucoup de traçage, j'ai finalement décidé de jeter un coup d'œil à la source et de voir ce qu'il y a.
dans "indexwriter", vous avez qui est pointé sur le SIMPLOCLOCLOCK la mise en oeuvre. Le coupable était en créant un nouveau thread, en interne, il jette un système.UnauthorizedAccessException, selon MSDN ici Lors du démarrage d'un nouveau thread, System.Security.Prinipal.WindowSidentity.getCurrent () renvoie l'identité du processus, pas nécessairement l'identité du code appelé thread.start (). Il est important de vous rappeler que lorsque vous démarrez des délégués ou des threads asynchrones dans un fil impersonné ASP.NET.
Si vous êtes dans ASP.NET et que vous souhaitez que le nouveau thread commence par la fenêtre de fabrication impersonnée, passez la fenêtre de la fenêtre à la méthode ThreadStart. Une fois dans la méthode threadstart, appelez windowsidity.Impsersonate ().
tel, j'ai résolu mon problème en impersonnez le compte IIS exécutant mon application dans la fonction "Exécuter ()" et tous les problèmes sont résolus. Merci à tous.
Eh bien, la façon normale de montrer votre merci est de uploter et / ou d'accepter la réponse :-)
J'ai mis à jour ma réponse pour incorporer ce que vous avez demandé dans votre commentaire.