Home » Forum


No announcement yet.

V7 gets stuck

  • Filter
  • Time
  • Show
Clear All
new posts

  • V7 gets stuck

    Windows Server 2008 (R2/64 bit). V6 installed and running properly. Installed V7 (build 1002) in separate program location. Started the 64-bit version. Opened up a working V6 config files. Changed the output folder to a new location; no other changes. Saved the config as a different name.

    Started the V7-64bit indexing process. About 10 minutes in (V6 takes about 50 minutes), the process appears to stop on the same file (as shown by the Indexer thread line). The file appears to load properly in a browser. (Publicly visible: http://www.slco.org/animalservices/html/headernav/eventcalendar/2013-01.html .)

    Have tried the same process with the V7-32bit, same problem. Removed multi-thread options on V7, same stop.

    Note that the V6 config, with a change to the output folder, was used in V7 with no other changes.

    After the apparent stop, I cannot 'stop indexing'; that button/process never completes. The 'stop file' (above) shows status of 'FInishing'. Only way to get out of it is to use Task Manager to kill the program. Have also tried server restart.

    Task manager shows minimal memory usage during indexing (8GB Ram in system, about 1.5 used). Lots of free disk space. 8 processor system.

    Have spent a full day on this, and can't get v7 to work. Next step?


  • #2
    The page you linked has two <body> tags. I suggest fixing the page code and see if that makes a difference.



    • #3
      Yes, the page has a bit of invalid HTML on it, but that shouldn't cause a lockup.

      We'll see if we can reproduce the problem here with this site.


      • #4
        Using V7.0 build 1003 32bit on Win7 64bit, I was able to index well past the 20min mark on the slco.org site. But we might be using a different configuration setup. It is a much bigger web site that it would initially appear to be from the home page.

        It also occurs to be that maybe you shouldn't be trying to index all of the calendar function on your web site. We often see cases where the calendar script on a web site works far into the future and far into the past. (e.g. years 0000 to 99999+). Which means there is a near infinite number of pages on the web site, with a page per day of each of the years

        Files indexed so far are around 10,000. How many did you get to before the lockup?
        Can you E-mail me your configuration file (xxxxxx.zcfg) so I can have another attempt using the identical configuration to what you are using.


        • #5
          Thanks. I just tried another index, and got stuck at a different spot than yesterday, but at the same spot twice today.

          I have noticed that the problem seems to occur with an xls download showing 100% progress, but those files never get to the indexer thread. See the screenshot; there are 9 threads that appear to be stuck, 7 are xls, and two are html.

          THis is slightly different than yesterday, where one of the same XLS files was in the DL threads at 100%, and two pdf files are also at 100% DL thread.

          First screenshot from this morning using 32 bit version, second from yesterday using 64 bit version. I will send the config file to you separately/privately. Note that the config file is the same one used with V6.

          I have notices that xls files will be 'stuck' at the 100% downloading thread entry. Eventually, even if there are still empty DL threads, the process will stop.

          (Can't get a picture inserted from the file system. Will email them separately.


          • #6
            After a log run (10,000+ files indexed) it did eventually 'lock up'. But after a timeout it did eventually continue, after a 30min pause. So it was more a timeout situation rather than a full lockup.

            The lockup was on this file.

            This file also fails to load up in Chrome and IE.

            The TCP/IP trace of the HTTP request to your server shows that your server never got around to sending any data from the PDF file. Instead, after a long time, your server eventually sends a TCP/IP [FIN, ACK] to drop the TCP/IP connection.

            So I think there are two problems,
            1) There is something wrong with your server or the PDF files.
            2) Zoom V7 is waiting too long to timeout. Zoom shouldn't wait 30min for the server to send a [FIN]. It should time out after maybe 3min of no data. Having said that the browsers appear to be behave in the same way and don't time out quickly.

            I have sent you an E-mail with some traces and screen shots that might help in working out what is wrong on the server side.