• Login
  • Register

DNN Forums

A community discussion page. We're starting from scratch, so...let's get the party started!

DNN 9.2.1 in Azure WebApp: Unable to create Lucene writer (lock file is in use)

You are not authorized to post a reply.
Sort:
Page 5 of 5 << < 12345


Basic Member


Posts:33
Basic Member

    I'll just chime in here a bit as this is a very specific issue with Azure, or any other "dynamic" cloud environment. There are really two things that come together, with the infrastructure of using Azure in a multi-instance situation for App Services, which can cause issues.

    1.) App Services uses an SMB Network Share for File System

    Behind the scenes, your "Home directory" for your application is actually a mounted Azure Blob Storage account. This is fantastic, as you don't have to worry about DFS Replication or otherwise as it relates to the file system when you go to scale-out. However, this can manifest itself as a bit of an ugly situation for DNN in a couple places.

    * Log4Net Logs - These are written to the /Portals/_default/logs directory, which being shared can have issues & writelocks. Often times this goes un-noticed, but can be addressed by changing the logging directory to the Azure suggested log directory. You can also, more than likely, adjust to include machine name, but I haven't done that yet.

    * Lucene Lock Files - They have the same issue, but there is a second issue that makes this a bigger deal
    * Third-party Solutions - You also want to look at any third-party items that you are using that write to the local filesystem as this infrastructure can cause issues if they, for example, use a "file-based" caching provider behind the scenes.

    2. DNN Scheduler Not Smart Enough for Dynamic Environments

    The second issue, or really the root cause, as you pointed out is the limitation of the DNN Scheduler to prevent execution on multiple servers. Currently, the DNN Platform has an ability to either execute a scheduled job on ALL servers, or a specific set of individually named servers. In the Azure App Service Environment, this doesn't work as your server name can change multiple times a day. There are a few workarounds.

    1.) You can run a regular SQL Script that queries the listing of known servers, and picks one to assign the task. It isn't elegant, but works.
    2.) You can do similar to what you mentioned with an out-of-band fork.

    Going Forward

    I have a plan, that I hope to be able to implement for 10.x that will introduce a few new features.

    * A "Run On Single Server" option for jobs, to only execute 1 time per time-period
    * A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

    If anyone wants to help work on those features, it would be appreciated.
    Mitchel Sellers
    Technology Advisory Group Leader
    CEO @ IowaComputerGurus, Inc. a DNN & .NET Solutions Provider
    Technical Blog: MitchelSellers.com


    New Member


    Posts:5
    New Member

      Hello Mitchel.

      Yes! The log4net issue is something we've seen but it's not as bad as the lucene lock files. I didn't think of changing the server dynamically. That may be an option but it needs to be coupled with a purge of inactive servers.

      We went with the solution of extending the search task class because we had already implemented a way of limiting the number simultaneous of executions for a custom scheduled task and it was more convenient.

      Thanks for your input. Hopefully this will help anyone facing the same issues.


      Basic Member


      Posts:45
      Basic Member

        Posted By Mitchel Sellers on 27 Jun 2019 10:14 AM
        * A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

        Ah yes, Evoq has this! :)

         



        Basic Member


        Posts:33
        Basic Member

          Posted By Olly Hodgson on 27 Jun 2019 01:46 PM
          Posted By Mitchel Sellers on 27 Jun 2019 10:14 AM
          * A "Cleanup Servers" job that will keep the server's table pruned from outdated servers

          Ah yes, Evoq has this! :)

           

          Yup!  And initially it was committed to be contributed to the platform, but that decision changed.  As such, we are going to have to build our own.

           

           

          Mitchel Sellers
          Technology Advisory Group Leader
          CEO @ IowaComputerGurus, Inc. a DNN & .NET Solutions Provider
          Technical Blog: MitchelSellers.com


          New Member


          Posts:1
          New Member

            Hi
            This error occurs when the search scheduler wants to restart according to the timing set in the section for the default timestamp. Indexing is indexed in files.
            My problem with this solution was solved
            From the Admin> Schedules> Search: Site Crawler section, edit the "Time lapse:" section to 12 hours. And set the "Retry Repeat:" section to 6 hours. This causes the rescheduling to not interfere with the previous timing and you will not receive the corresponding error. And the problem of indexing searches regularly.
            https://dnnplus.ir/Forum/g/posts/t/703/%d8%ae%d8%b7%d8%a7%db%8c-%d8%b2%d9%85%d8%a7%d9%86%d8%a8%d9%86%d8%af-%d8%ac%d8%b3%d8%aa%d9%88%d8%ac%d9%88-%d8%a8%d8%b9%d8%af-%d8%a7%d8%b2-%d8%a7%d9%be%d8%af%db%8c%d8%aa-%d8%a8%d9%87-%d9%86%d8%b3%d8%ae%d9%87-9-4-1

            You are not authorized to post a reply.
            Page 5 of 5 << < 12345

            These Forums are dedicated to discussion of DNN Platform.

            For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

            1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
            2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
            3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
            4. No Flaming or Trolling.
            5. No Profanity, Racism, or Prejudice.
            6. Site Moderators have the final word on approving / removing a thread or post or comment.
            7. English language posting only, please.

            Would you like to help us?

            Awesome! Simply post in the forums using the link below and we'll get you started.

            Get Involved