Solr
  1. Solr
  2. SOLR-1757

DIH multithreading sometimes throws NPE

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Labels:
    • Environment:

      tomcat 6.0.x, jdk 1.6.x on windows xp 32bit

      Description

      When the "threads" attribute is set on a root entity in the DIH's data-config.xml, the multithreading code sometimes throws a NullPointerException after the full-index command is given.

      I haven't yet been able to figure out exactly which reference holds the null or why, but it does happen consistently with the same backtrace.

      My configuration is:

      1. Multi-core Solr under tomcat
      2. Using JdbcDataSource and the default SqlEntityProcessor

      To reproduce:

      1. Add the attribute threads="2" to the root entity declaration in data-config.xml
      2. Send the full-import command either directly to .../core/dataimport?command=full-import or through the /admin/dataimport.jsp control panel.
      3. Wait for the NPE to show up in the logs/console

      1. solr-1352-threads-bt.txt
        3 kB
        Michael Henson
      2. SOLR-1757.patch
        3 kB
        Noble Paul
      3. solr-1757-abort-threaddump.zip
        3 kB
        Michael Henson

        Activity

        Hide
        Michael Henson added a comment -

        This is the backtrace I get with this NPE. The backtrace is always the same, though I haven't confirmed whether or not it happens with the same data or after the same number of rows have been processed. The redacted part of the backtrace looked normal - no missing fields, no empty values.

        Show
        Michael Henson added a comment - This is the backtrace I get with this NPE. The backtrace is always the same, though I haven't confirmed whether or not it happens with the same data or after the same number of rows have been processed. The redacted part of the backtrace looked normal - no missing fields, no empty values.
        Hide
        Michael Henson added a comment -

        The patch works to get it running. Now the issue is that the process doesn't stop after an "abort" command is given.

        Show
        Michael Henson added a comment - The patch works to get it running. Now the issue is that the process doesn't stop after an "abort" command is given.
        Hide
        Noble Paul added a comment -

        thanks Micheal. I'll commit this soon

        could you help me w/ the thread dumps after the abort.

        Show
        Noble Paul added a comment - thanks Micheal. I'll commit this soon could you help me w/ the thread dumps after the abort.
        Hide
        Michael Henson added a comment -

        This is the ../admin/threaddjump.jsp page for the core configured with threads="3", running a full-import, after having sent it the abort command.

        Show
        Michael Henson added a comment - This is the ../admin/threaddjump.jsp page for the core configured with threads="3", running a full-import, after having sent it the abort command.
        Hide
        Noble Paul added a comment -

        I guess you have pasted the wrong stacktrace.

        We can close this issue and open another for the persistent threads after abort command

        Show
        Noble Paul added a comment - I guess you have pasted the wrong stacktrace. We can close this issue and open another for the persistent threads after abort command
        Hide
        Noble Paul added a comment -

        comitted r907935

        Show
        Noble Paul added a comment - comitted r907935

          People

          • Assignee:
            Noble Paul
            Reporter:
            Michael Henson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development