Solr
  1. Solr
  2. SOLR-4358

SolrJ, by preventing multi-part post, loses key information about file name that Tika needs

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.4, 6.0
    • Component/s: clients - java
    • Labels:
      None

      Description

      SolrJ accepts a ContentStream, which has a name field. Within HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this filename is transmitted as part of the form boundary information. However, if SolrJ chooses not to use multipart post, the filename information is lost.

      This information is used by SolrCell (Tika) to make decisions about content extraction, so it is very important that it makes it into Solr in one way or another. Either SolrJ should set appropriate equivalent headers to send the filename automatically, or it should force multipart posts when this information is present.

      1. additional_changes.diff
        3 kB
        Karl Wright
      2. SOLR-4358.patch
        5 kB
        Ryan McKinley
      3. SOLR-4358.patch
        4 kB
        Ryan McKinley
      4. SOLR-4358.patch
        3 kB
        Karl Wright

        Issue Links

          Activity

          Hide
          Jan Høydahl added a comment -

          SolrCell will use resource.name request param as filename hint. The application using SolrJ can set this. Not sure if SolrJ really should be closesly tied to SolrCell params, SolrCell being a contrib module..

          Show
          Jan Høydahl added a comment - SolrCell will use resource.name request param as filename hint. The application using SolrJ can set this. Not sure if SolrJ really should be closesly tied to SolrCell params, SolrCell being a contrib module..
          Hide
          Karl Wright added a comment -

          My point is independent of SolrCell. If anything in Solr were to care about the filename in a multipart post, then if SolrJ is making the decision to use standard POST vs multipart, it should also take care to eliminate any resulting differences in the Solr environment. If SolrJ gives the user control over the posting method, then I don't care if SolrJ tries to fix this or not.

          Show
          Karl Wright added a comment - My point is independent of SolrCell. If anything in Solr were to care about the filename in a multipart post, then if SolrJ is making the decision to use standard POST vs multipart, it should also take care to eliminate any resulting differences in the Solr environment. If SolrJ gives the user control over the posting method, then I don't care if SolrJ tries to fix this or not.
          Hide
          Karl Wright added a comment -

          Here's a patch that does essentially what I think is wanted.

          Show
          Karl Wright added a comment - Here's a patch that does essentially what I think is wanted.
          Hide
          Ryan McKinley added a comment -

          updated patch to allow get/set useMultiPartPost

          Show
          Ryan McKinley added a comment - updated patch to allow get/set useMultiPartPost
          Hide
          Ryan McKinley added a comment -

          Manifold Connectors uses Solrj and should be able to force multipart requests

          Show
          Ryan McKinley added a comment - Manifold Connectors uses Solrj and should be able to force multipart requests
          Hide
          Ryan McKinley added a comment -

          added to trunk and 4x

          Show
          Ryan McKinley added a comment - added to trunk and 4x
          Hide
          Hoss Man added a comment -

          As noted by Uwe on the dev list, the changes committed for this issue seem ot have caused various test failures, as well as sending ChaosMonkeySafeLeader into an infinite loop(?!)

          Re-opening to investigate - likely need to roll back these changes if we can't get to the bottom of things right away

          Show
          Hoss Man added a comment - As noted by Uwe on the dev list, the changes committed for this issue seem ot have caused various test failures, as well as sending ChaosMonkeySafeLeader into an infinite loop(?!) Re-opening to investigate - likely need to roll back these changes if we can't get to the bottom of things right away
          Hide
          Ryan McKinley added a comment -

          sorry... digging now...

          Show
          Ryan McKinley added a comment - sorry... digging now...
          Hide
          Uwe Schindler added a comment -

          I stopped Jenkins builds until this is fixed/reverted, because the Windows Jenkins machine needed to be killed hard because ChaosMonkeySafeLeaderTest was eating all virtual CPUs available, making it impossible to shut down the virtual machine or stop tests other than hitting the virtual PowerOff button
          Under Linux, only kill -9 stops ChaosMonkey.

          Show
          Uwe Schindler added a comment - I stopped Jenkins builds until this is fixed/reverted, because the Windows Jenkins machine needed to be killed hard because ChaosMonkeySafeLeaderTest was eating all virtual CPUs available, making it impossible to shut down the virtual machine or stop tests other than hitting the virtual PowerOff button Under Linux, only kill -9 stops ChaosMonkey.
          Hide
          Ryan McKinley added a comment -

          reverted in trunk & 4.x

          I can't figure out what is causing the problem though... will keep digging.

          Show
          Ryan McKinley added a comment - reverted in trunk & 4.x I can't figure out what is causing the problem though... will keep digging.
          Hide
          Uwe Schindler added a comment -

          Thanks, I reenabled Jenkins builds.

          Show
          Uwe Schindler added a comment - Thanks, I reenabled Jenkins builds.
          Hide
          Karl Wright added a comment -

          Diff of additional changes I needed to include in order to get multipart post working again

          Show
          Karl Wright added a comment - Diff of additional changes I needed to include in order to get multipart post working again
          Hide
          Ryan McKinley added a comment -

          Here is an updated patch.

          It adds 'setUseMultipart(true)' into the random test configs.

          BUT it seems to have issues with ZK distributed search. I don't know if that is just a test/environmet issue on my side or a real issue. But I get this failure:

          Tests with failures:
           -org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch
          
          
          Show
          Ryan McKinley added a comment - Here is an updated patch. It adds 'setUseMultipart(true)' into the random test configs. BUT it seems to have issues with ZK distributed search. I don't know if that is just a test/environmet issue on my side or a real issue. But I get this failure: Tests with failures: -org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch
          Hide
          Karl Wright added a comment -

          Why would SolrCloud be affected at all by an HttpSolrServer.java change?

          Show
          Karl Wright added a comment - Why would SolrCloud be affected at all by an HttpSolrServer.java change?
          Hide
          Ryan McKinley added a comment -

          SolrCloud/Distributed search uses HttpSolrServer for internal communication – so something must be fishy.

          It is not clear to me how the tests are failing – just that they are.

          Show
          Ryan McKinley added a comment - SolrCloud/Distributed search uses HttpSolrServer for internal communication – so something must be fishy. It is not clear to me how the tests are failing – just that they are.
          Hide
          Karl Wright added a comment -

          Ok - looking into it.

          Show
          Karl Wright added a comment - Ok - looking into it.
          Hide
          Karl Wright added a comment -

          The test that fails for me is:

          [junit4:junit4] Tests with failures:
          [junit4:junit4]   - org.apache.solr.cloud.AliasIntegrationTest.testDistribSearch
          
          [junit4:junit4]   - org.apache.solr.cloud.AliasIntegrationTest (suite)
          [junit4:junit4]
          

          This on branch_4x. Perhaps the test was renamed on trunk? Anyhow, the failure looks suspiciously like I tripped over a local disk error:

            2> Creating dataDir: C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\solrtest-AliasIntegrationTest-1366356503950
            2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1\index\org.apache.lucene.store.RAMDirectory@1f24a78 lockFactory=org.apache.lucene.store.NativeFSLockFactory@15b0c83-write.lock FAILED !!!!!
            2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1\index FAILED !!!!!
            2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1 FAILED !!!!!
            2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947 FAILED !!!!!
            2> NOTE: reproduce with: ant test  -Dtestcase=AliasIntegrationTest -Dtests.method=testDistribSearch -Dtests.seed=964155E88FA3F7F -Dtests.slow=true -Dtests.locale=en_PH -Dtests.timezone=Etc/GMT0 -Dtests.file.encoding=Cp1252
          [03:28:23.944] ERROR   53.9s | AliasIntegrationTest.testDistribSearch <<<
             > Throwable #1: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://127.0.0.1:56486/_hfw/testalias returned non ok status:500, message:Server Error
             > 	at __randomizedtesting.SeedInfo.seed([964155E88FA3F7F:88829B46FFA55F43]:0)
             > 	at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
             > 	at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
             > 	at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
             > 	at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
             > 	at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
             > 	at org.apache.solr.cloud.AliasIntegrationTest.doTest(AliasIntegrationTest.java:213)
             > 	at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:806)
          

          On repeat, the test succeeded. Obviously something random about the SolrCloud tests in general, I think. So I will rerun until I'm satisfied no test fails repeatably.

          Show
          Karl Wright added a comment - The test that fails for me is: [junit4:junit4] Tests with failures: [junit4:junit4] - org.apache.solr.cloud.AliasIntegrationTest.testDistribSearch [junit4:junit4] - org.apache.solr.cloud.AliasIntegrationTest (suite) [junit4:junit4] This on branch_4x. Perhaps the test was renamed on trunk? Anyhow, the failure looks suspiciously like I tripped over a local disk error: 2> Creating dataDir: C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\solrtest-AliasIntegrationTest-1366356503950 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1\index\org.apache.lucene.store.RAMDirectory@1f24a78 lockFactory=org.apache.lucene.store.NativeFSLockFactory@15b0c83-write.lock FAILED !!!!! 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1\index FAILED !!!!! 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947\jetty1 FAILED !!!!! 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\solr\build\solr-core\test\J0\.\org.apache.solr.cloud.AliasIntegrationTest-1366356503947 FAILED !!!!! 2> NOTE: reproduce with: ant test -Dtestcase=AliasIntegrationTest -Dtests.method=testDistribSearch -Dtests.seed=964155E88FA3F7F -Dtests.slow= true -Dtests.locale=en_PH -Dtests.timezone=Etc/GMT0 -Dtests.file.encoding=Cp1252 [03:28:23.944] ERROR 53.9s | AliasIntegrationTest.testDistribSearch <<< > Throwable #1: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http: //127.0.0.1:56486/_hfw/testalias returned non ok status:500, message:Server Error > at __randomizedtesting.SeedInfo.seed([964155E88FA3F7F:88829B46FFA55F43]:0) > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385) > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) > at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) > at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116) > at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102) > at org.apache.solr.cloud.AliasIntegrationTest.doTest(AliasIntegrationTest.java:213) > at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:806) On repeat, the test succeeded. Obviously something random about the SolrCloud tests in general, I think. So I will rerun until I'm satisfied no test fails repeatably.
          Hide
          Karl Wright added a comment -

          Ok, I found one that fails repeatably - but it seems to fail not due to HttpSolrServer but due to problems shutting down threads.

          This is how to repeat it:

          ant test -Dtestcase=BasicDistributedZk2Test -Dtests.seed=398C285200313054 -Dtests.slow=true -Dtests.locale=uk_UA -Dtests.timezone=Africa/Kigali -Dtests.file.encoding=Cp1252

          The error it gets is this:

          [junit4:junit4]   2> Creating dataDir: C:\wip\solr\branch_4x\solr\build\solr-cor
          e\test\J0\.\solrtest-BasicDistributedZk2Test-1366359983221
          [junit4:junit4]   2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s
          olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366
          359983220\jetty2\index\org.apache.lucene.store.RAMDirectory@10c6406 lockFactory=
          org.apache.lucene.store.NativeFSLockFactory@2573a8-write.lock FAILED !!!!!
          [junit4:junit4]   2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s
          olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366
          359983220\jetty2\index FAILED !!!!!
          [junit4:junit4]   2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s
          olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366
          359983220\jetty2 FAILED !!!!!
          [junit4:junit4]   2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s
          olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366
          359983220 FAILED !!!!!
          [junit4:junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=BasicDistributed
          Zk2Test -Dtests.method=testDistribSearch -Dtests.seed=398C285200313054 -Dtests.s
          low=true -Dtests.locale=uk_UA -Dtests.timezone=Africa/Kigali -Dtests.file.encodi
          ng=Cp1252
          [junit4:junit4] ERROR   57.2s | BasicDistributedZk2Test.testDistribSearch <<<
          [junit4:junit4]    > Throwable #1: org.apache.solr.client.solrj.impl.HttpSolrSer
          ver$RemoteSolrException: Server at http://127.0.0.1:59625/onenodecollectioncore
          returned non ok status:500, message:Server Error
          [junit4:junit4]    >    at __randomizedtesting.SeedInfo.seed([398C285200313054:B
          86AA64A776E5068]:0)
          [junit4:junit4]    >    at org.apache.solr.client.solrj.impl.HttpSolrServer.requ
          est(HttpSolrServer.java:385)
          [junit4:junit4]    >    at org.apache.solr.client.solrj.impl.HttpSolrServer.requ
          est(HttpSolrServer.java:180)
          [junit4:junit4]    >    at org.apache.solr.client.solrj.request.AbstractUpdateRe
          quest.process(AbstractUpdateRequest.java:117)
          [junit4:junit4]    >    at org.apache.solr.client.solrj.SolrServer.add(SolrServe
          r.java:116)
          [junit4:junit4]    >    at org.apache.solr.client.solrj.SolrServer.add(SolrServe
          r.java:102)
          [junit4:junit4]    >    at org.apache.solr.cloud.BasicDistributedZk2Test.testNod
          eWithoutCollectionForwarding(BasicDistributedZk2Test.java:197)
          [junit4:junit4]    >    at org.apache.solr.cloud.BasicDistributedZk2Test.doTest(
          BasicDistributedZk2Test.java:89)
          [junit4:junit4]    >    at org.apache.solr.BaseDistributedSearchTestCase.testDis
          tribSearch(BaseDistributedSearchTestCase.java:806)
          [junit4:junit4]    >    at java.lang.Thread.run(Thread.java:619)
          [junit4:junit4]   1> INFO  - 2013-04-19 04:27:20.374; org.apache.solr.SolrTestCa
          seJ4; ###deleteCore
          [junit4:junit4] HEARTBEAT J0 PID(14064@acromantula): 2013-04-19T04:28:30, stalle
          d for 69.7s at: BasicDistributedZk2Test.testDistribSearch
          [junit4:junit4]   1> ERROR - 2013-04-19 04:29:21.383; org.apache.solr.SolrTestCa
          seJ4; ERROR: SolrIndexSearcher opens=10 closes=8
          [junit4:junit4]   2> 178598 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING Wi
          ll linger awaiting termination of 1 leaked thread(s).
          [junit4:junit4] HEARTBEAT J0 PID(14064@acromantula): 2013-04-19T04:29:30, stalle
          d for  130s at: BasicDistributedZk2Test.testDistribSearch
          [junit4:junit4]   2> 198601 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1 t
          hread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZk2Test:
          
          [junit4:junit4]   2>       1) Thread[id=71, name=searcherExecutor-25-thread-1, s
          tate=WAITING, group=TGRP-BasicDistributedZk2Test]
          [junit4:junit4]   2>            at sun.misc.Unsafe.park(Native Method)
          [junit4:junit4]   2>            at java.util.concurrent.locks.LockSupport.park(L
          ockSupport.java:158)
          [junit4:junit4]   2>            at java.util.concurrent.locks.AbstractQueuedSync
          hronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
          [junit4:junit4]   2>            at java.util.concurrent.LinkedBlockingQueue.take
          (LinkedBlockingQueue.java:399)
          [junit4:junit4]   2>            at java.util.concurrent.ThreadPoolExecutor.getTa
          sk(ThreadPoolExecutor.java:947)
          [junit4:junit4]   2>            at java.util.concurrent.ThreadPoolExecutor$Worke
          r.run(ThreadPoolExecutor.java:907)
          [junit4:junit4]   2>            at java.lang.Thread.run(Thread.java:619)
          [junit4:junit4]   2> 198601 T9 ccr.ThreadLeakControl.tryToInterruptAll Starting
          to interrupt leaked threads:
          [junit4:junit4]   2>       1) Thread[id=71, name=searcherExecutor-25-thread-1, s
          tate=WAITING, group=TGRP-BasicDistributedZk2Test]
          [junit4:junit4]   2> 201602 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE Th
          ere are still zombie threads that couldn't be terminated:
          [junit4:junit4]   2>       1) Thread[id=71, name=searcherExecutor-25-thread-1, s
          tate=WAITING, group=TGRP-BasicDistributedZk2Test]
          [junit4:junit4]   2>            at sun.misc.Unsafe.park(Native Method)
          [junit4:junit4]   2>            at java.util.concurrent.locks.LockSupport.park(L
          ockSupport.java:158)
          [junit4:junit4]   2>            at java.util.concurrent.locks.AbstractQueuedSync
          hronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
          [junit4:junit4]   2>            at java.util.concurrent.LinkedBlockingQueue.take
          (LinkedBlockingQueue.java:399)
          [junit4:junit4]   2>            at java.util.concurrent.ThreadPoolExecutor.getTa
          sk(ThreadPoolExecutor.java:947)
          [junit4:junit4]   2>            at java.util.concurrent.ThreadPoolExecutor$Worke
          r.run(ThreadPoolExecutor.java:907)
          [junit4:junit4]   2>            at java.lang.Thread.run(Thread.java:619)
          [junit4:junit4]   2> NOTE: test params are: codec=Lucene42: {}, docValues:{}, si
          m=DefaultSimilarity, locale=uk_UA, timezone=Africa/Kigali
          [junit4:junit4]   2> NOTE: Windows Vista 6.0 x86/Sun Microsystems Inc. 1.6.0_21
          (32-bit)/cpus=2,threads=2,free=8746296,total=33193984
          [junit4:junit4]   2> NOTE: All tests run in this JVM: [BasicDistributedZk2Test]
          [junit4:junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=BasicDistributed
          Zk2Test -Dtests.seed=398C285200313054 -Dtests.slow=true -Dtests.locale=uk_UA -Dt
          ests.timezone=Africa/Kigali -Dtests.file.encoding=Cp1252
          [junit4:junit4] ERROR   0.00s | BasicDistributedZk2Test (suite) <<<
          [junit4:junit4]    > Throwable #1: java.lang.AssertionError: ERROR: SolrIndexSea
          rcher opens=10 closes=8
          [junit4:junit4]    >    at __randomizedtesting.SeedInfo.seed([398C285200313054]:
          0)
          [junit4:junit4]    >    at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(S
          olrTestCaseJ4.java:252)
          [junit4:junit4]    >    at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCas
          eJ4.java:101)
          [junit4:junit4]    >    at java.lang.Thread.run(Thread.java:619)Throwable #2: co
          m.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE sco
          pe at org.apache.solr.cloud.BasicDistributedZk2Test:
          [junit4:junit4]    >    1) Thread[id=71, name=searcherExecutor-25-thread-1, stat
          e=WAITING, group=TGRP-BasicDistributedZk2Test]
          [junit4:junit4]    >         at sun.misc.Unsafe.park(Native Method)
          [junit4:junit4]    >         at java.util.concurrent.locks.LockSupport.park(Lock
          Support.java:158)
          [junit4:junit4]    >         at java.util.concurrent.locks.AbstractQueuedSynchro
          nizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
          [junit4:junit4]    >         at java.util.concurrent.LinkedBlockingQueue.take(Li
          nkedBlockingQueue.java:399)
          [junit4:junit4]    >         at java.util.concurrent.ThreadPoolExecutor.getTask(
          ThreadPoolExecutor.java:947)
          [junit4:junit4]    >         at java.util.concurrent.ThreadPoolExecutor$Worker.r
          un(ThreadPoolExecutor.java:907)
          [junit4:junit4]    >         at java.lang.Thread.run(Thread.java:619)
          [junit4:junit4]    >    at __randomizedtesting.SeedInfo.seed([398C285200313054]:
          0)Throwable #3: com.carrotsearch.randomizedtesting.ThreadLeakError: There are st
          ill zombie threads that couldn't be terminated:
          [junit4:junit4]    >    1) Thread[id=71, name=searcherExecutor-25-thread-1, stat
          e=WAITING, group=TGRP-BasicDistributedZk2Test]
          [junit4:junit4]    >         at sun.misc.Unsafe.park(Native Method)
          [junit4:junit4]    >         at java.util.concurrent.locks.LockSupport.park(Lock
          Support.java:158)
          [junit4:junit4]    >         at java.util.concurrent.locks.AbstractQueuedSynchro
          nizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
          [junit4:junit4]    >         at java.util.concurrent.LinkedBlockingQueue.take(Li
          nkedBlockingQueue.java:399)
          [junit4:junit4]    >         at java.util.concurrent.ThreadPoolExecutor.getTask(
          ThreadPoolExecutor.java:947)
          [junit4:junit4]    >         at java.util.concurrent.ThreadPoolExecutor$Worker.r
          un(ThreadPoolExecutor.java:907)
          [junit4:junit4]    >         at java.lang.Thread.run(Thread.java:619)
          [junit4:junit4]    >    at __randomizedtesting.SeedInfo.seed([398C285200313054]:
          0)
          [junit4:junit4] Completed in 203.91s, 1 test, 1 failure, 3 errors <<< FAILURES!
          [junit4:junit4]
          [junit4:junit4]
          [junit4:junit4] Tests with failures:
          [junit4:junit4]   - org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSea
          rch
          [junit4:junit4]   - org.apache.solr.cloud.BasicDistributedZk2Test (suite)
          [junit4:junit4]
          [junit4:junit4]
          [junit4:junit4] JVM J0:     1.55 ..   206.98 =   205.43s
          [junit4:junit4] Execution time total: 3 minutes 27 seconds
          [junit4:junit4] Tests summary: 1 suite, 1 test, 3 suite-level errors, 1 error
          
          BUILD FAILED
          

          I don't think this is related to the patch for this ticket, but to be sure I'll peel the patch out and try it again.

          Show
          Karl Wright added a comment - Ok, I found one that fails repeatably - but it seems to fail not due to HttpSolrServer but due to problems shutting down threads. This is how to repeat it: ant test -Dtestcase=BasicDistributedZk2Test -Dtests.seed=398C285200313054 -Dtests.slow=true -Dtests.locale=uk_UA -Dtests.timezone=Africa/Kigali -Dtests.file.encoding=Cp1252 The error it gets is this: [junit4:junit4] 2> Creating dataDir: C:\wip\solr\branch_4x\solr\build\solr-cor e\test\J0\.\solrtest-BasicDistributedZk2Test-1366359983221 [junit4:junit4] 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366 359983220\jetty2\index\org.apache.lucene.store.RAMDirectory@10c6406 lockFactory= org.apache.lucene.store.NativeFSLockFactory@2573a8-write.lock FAILED !!!!! [junit4:junit4] 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366 359983220\jetty2\index FAILED !!!!! [junit4:junit4] 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366 359983220\jetty2 FAILED !!!!! [junit4:junit4] 2> !!!! WARNING: best effort to remove C:\wip\solr\branch_4x\s olr\build\solr-core\test\J0\.\org.apache.solr.cloud.BasicDistributedZk2Test-1366 359983220 FAILED !!!!! [junit4:junit4] 2> NOTE: reproduce with: ant test -Dtestcase=BasicDistributed Zk2Test -Dtests.method=testDistribSearch -Dtests.seed=398C285200313054 -Dtests.s low= true -Dtests.locale=uk_UA -Dtests.timezone=Africa/Kigali -Dtests.file.encodi ng=Cp1252 [junit4:junit4] ERROR 57.2s | BasicDistributedZk2Test.testDistribSearch <<< [junit4:junit4] > Throwable #1: org.apache.solr.client.solrj.impl.HttpSolrSer ver$RemoteSolrException: Server at http: //127.0.0.1:59625/onenodecollectioncore returned non ok status:500, message:Server Error [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([398C285200313054:B 86AA64A776E5068]:0) [junit4:junit4] > at org.apache.solr.client.solrj.impl.HttpSolrServer.requ est(HttpSolrServer.java:385) [junit4:junit4] > at org.apache.solr.client.solrj.impl.HttpSolrServer.requ est(HttpSolrServer.java:180) [junit4:junit4] > at org.apache.solr.client.solrj.request.AbstractUpdateRe quest.process(AbstractUpdateRequest.java:117) [junit4:junit4] > at org.apache.solr.client.solrj.SolrServer.add(SolrServe r.java:116) [junit4:junit4] > at org.apache.solr.client.solrj.SolrServer.add(SolrServe r.java:102) [junit4:junit4] > at org.apache.solr.cloud.BasicDistributedZk2Test.testNod eWithoutCollectionForwarding(BasicDistributedZk2Test.java:197) [junit4:junit4] > at org.apache.solr.cloud.BasicDistributedZk2Test.doTest( BasicDistributedZk2Test.java:89) [junit4:junit4] > at org.apache.solr.BaseDistributedSearchTestCase.testDis tribSearch(BaseDistributedSearchTestCase.java:806) [junit4:junit4] > at java.lang. Thread .run( Thread .java:619) [junit4:junit4] 1> INFO - 2013-04-19 04:27:20.374; org.apache.solr.SolrTestCa seJ4; ###deleteCore [junit4:junit4] HEARTBEAT J0 PID(14064@acromantula): 2013-04-19T04:28:30, stalle d for 69.7s at: BasicDistributedZk2Test.testDistribSearch [junit4:junit4] 1> ERROR - 2013-04-19 04:29:21.383; org.apache.solr.SolrTestCa seJ4; ERROR: SolrIndexSearcher opens=10 closes=8 [junit4:junit4] 2> 178598 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING Wi ll linger awaiting termination of 1 leaked thread(s). [junit4:junit4] HEARTBEAT J0 PID(14064@acromantula): 2013-04-19T04:29:30, stalle d for 130s at: BasicDistributedZk2Test.testDistribSearch [junit4:junit4] 2> 198601 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1 t hread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZk2Test: [junit4:junit4] 2> 1) Thread [id=71, name=searcherExecutor-25-thread-1, s tate=WAITING, group=TGRP-BasicDistributedZk2Test] [junit4:junit4] 2> at sun.misc.Unsafe.park(Native Method) [junit4:junit4] 2> at java.util.concurrent.locks.LockSupport.park(L ockSupport.java:158) [junit4:junit4] 2> at java.util.concurrent.locks.AbstractQueuedSync hronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) [junit4:junit4] 2> at java.util.concurrent.LinkedBlockingQueue.take (LinkedBlockingQueue.java:399) [junit4:junit4] 2> at java.util.concurrent.ThreadPoolExecutor.getTa sk(ThreadPoolExecutor.java:947) [junit4:junit4] 2> at java.util.concurrent.ThreadPoolExecutor$Worke r.run(ThreadPoolExecutor.java:907) [junit4:junit4] 2> at java.lang. Thread .run( Thread .java:619) [junit4:junit4] 2> 198601 T9 ccr.ThreadLeakControl.tryToInterruptAll Starting to interrupt leaked threads: [junit4:junit4] 2> 1) Thread [id=71, name=searcherExecutor-25-thread-1, s tate=WAITING, group=TGRP-BasicDistributedZk2Test] [junit4:junit4] 2> 201602 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE Th ere are still zombie threads that couldn't be terminated: [junit4:junit4] 2> 1) Thread [id=71, name=searcherExecutor-25-thread-1, s tate=WAITING, group=TGRP-BasicDistributedZk2Test] [junit4:junit4] 2> at sun.misc.Unsafe.park(Native Method) [junit4:junit4] 2> at java.util.concurrent.locks.LockSupport.park(L ockSupport.java:158) [junit4:junit4] 2> at java.util.concurrent.locks.AbstractQueuedSync hronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) [junit4:junit4] 2> at java.util.concurrent.LinkedBlockingQueue.take (LinkedBlockingQueue.java:399) [junit4:junit4] 2> at java.util.concurrent.ThreadPoolExecutor.getTa sk(ThreadPoolExecutor.java:947) [junit4:junit4] 2> at java.util.concurrent.ThreadPoolExecutor$Worke r.run(ThreadPoolExecutor.java:907) [junit4:junit4] 2> at java.lang. Thread .run( Thread .java:619) [junit4:junit4] 2> NOTE: test params are: codec=Lucene42: {}, docValues:{}, si m=DefaultSimilarity, locale=uk_UA, timezone=Africa/Kigali [junit4:junit4] 2> NOTE: Windows Vista 6.0 x86/Sun Microsystems Inc. 1.6.0_21 (32-bit)/cpus=2,threads=2,free=8746296,total=33193984 [junit4:junit4] 2> NOTE: All tests run in this JVM: [BasicDistributedZk2Test] [junit4:junit4] 2> NOTE: reproduce with: ant test -Dtestcase=BasicDistributed Zk2Test -Dtests.seed=398C285200313054 -Dtests.slow= true -Dtests.locale=uk_UA -Dt ests.timezone=Africa/Kigali -Dtests.file.encoding=Cp1252 [junit4:junit4] ERROR 0.00s | BasicDistributedZk2Test (suite) <<< [junit4:junit4] > Throwable #1: java.lang.AssertionError: ERROR: SolrIndexSea rcher opens=10 closes=8 [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([398C285200313054]: 0) [junit4:junit4] > at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(S olrTestCaseJ4.java:252) [junit4:junit4] > at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCas eJ4.java:101) [junit4:junit4] > at java.lang. Thread .run( Thread .java:619)Throwable #2: co m.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE sco pe at org.apache.solr.cloud.BasicDistributedZk2Test: [junit4:junit4] > 1) Thread [id=71, name=searcherExecutor-25-thread-1, stat e=WAITING, group=TGRP-BasicDistributedZk2Test] [junit4:junit4] > at sun.misc.Unsafe.park(Native Method) [junit4:junit4] > at java.util.concurrent.locks.LockSupport.park(Lock Support.java:158) [junit4:junit4] > at java.util.concurrent.locks.AbstractQueuedSynchro nizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) [junit4:junit4] > at java.util.concurrent.LinkedBlockingQueue.take(Li nkedBlockingQueue.java:399) [junit4:junit4] > at java.util.concurrent.ThreadPoolExecutor.getTask( ThreadPoolExecutor.java:947) [junit4:junit4] > at java.util.concurrent.ThreadPoolExecutor$Worker.r un(ThreadPoolExecutor.java:907) [junit4:junit4] > at java.lang. Thread .run( Thread .java:619) [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([398C285200313054]: 0)Throwable #3: com.carrotsearch.randomizedtesting.ThreadLeakError: There are st ill zombie threads that couldn't be terminated: [junit4:junit4] > 1) Thread [id=71, name=searcherExecutor-25-thread-1, stat e=WAITING, group=TGRP-BasicDistributedZk2Test] [junit4:junit4] > at sun.misc.Unsafe.park(Native Method) [junit4:junit4] > at java.util.concurrent.locks.LockSupport.park(Lock Support.java:158) [junit4:junit4] > at java.util.concurrent.locks.AbstractQueuedSynchro nizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) [junit4:junit4] > at java.util.concurrent.LinkedBlockingQueue.take(Li nkedBlockingQueue.java:399) [junit4:junit4] > at java.util.concurrent.ThreadPoolExecutor.getTask( ThreadPoolExecutor.java:947) [junit4:junit4] > at java.util.concurrent.ThreadPoolExecutor$Worker.r un(ThreadPoolExecutor.java:907) [junit4:junit4] > at java.lang. Thread .run( Thread .java:619) [junit4:junit4] > at __randomizedtesting.SeedInfo.seed([398C285200313054]: 0) [junit4:junit4] Completed in 203.91s, 1 test, 1 failure, 3 errors <<< FAILURES! [junit4:junit4] [junit4:junit4] [junit4:junit4] Tests with failures: [junit4:junit4] - org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSea rch [junit4:junit4] - org.apache.solr.cloud.BasicDistributedZk2Test (suite) [junit4:junit4] [junit4:junit4] [junit4:junit4] JVM J0: 1.55 .. 206.98 = 205.43s [junit4:junit4] Execution time total: 3 minutes 27 seconds [junit4:junit4] Tests summary: 1 suite, 1 test, 3 suite-level errors, 1 error BUILD FAILED I don't think this is related to the patch for this ticket, but to be sure I'll peel the patch out and try it again.
          Hide
          Karl Wright added a comment -

          Yup, test fails even with patch removed. So it's not the patch.

          Show
          Karl Wright added a comment - Yup, test fails even with patch removed. So it's not the patch.
          Hide
          Ryan McKinley added a comment -

          this just passed on my local trunk checkout... I will commit and make sure jenkins is happy with trunk.

          If it is, I will merge to 4.x

          Show
          Ryan McKinley added a comment - this just passed on my local trunk checkout... I will commit and make sure jenkins is happy with trunk. If it is, I will merge to 4.x
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] ryan
          http://svn.apache.org/viewvc?view=revision&revision=1469946

          SOLR-4358: HttpSolrServer now supports forcing multipart requests

          Show
          Commit Tag Bot added a comment - [trunk commit] ryan http://svn.apache.org/viewvc?view=revision&revision=1469946 SOLR-4358 : HttpSolrServer now supports forcing multipart requests
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] ryan
          http://svn.apache.org/viewvc?view=revision&revision=1470023

          SOLR-4358: HttpSolrServer now supports forcing multipart requests
          ........
          Merged revision(s) 1469946 from lucene/dev/trunk:

          Show
          Commit Tag Bot added a comment - [branch_4x commit] ryan http://svn.apache.org/viewvc?view=revision&revision=1470023 SOLR-4358 : HttpSolrServer now supports forcing multipart requests ........ Merged revision(s) 1469946 from lucene/dev/trunk:
          Hide
          Ryan McKinley added a comment -

          just added to trunk and 4.x

          I'll keep an eye on jenkins and hope this does not cause failures

          Show
          Ryan McKinley added a comment - just added to trunk and 4.x I'll keep an eye on jenkins and hope this does not cause failures
          Hide
          Karl Wright added a comment -

          Has this ticket fix been pulled up into the latest RC for Solr 4.3?

          Show
          Karl Wright added a comment - Has this ticket fix been pulled up into the latest RC for Solr 4.3?
          Hide
          Shawn Heisey added a comment -

          Karl Wright It has been committed into trunk (5.0) and branch_4x (4.4). The commits happened on April 19th, which is after the 4.3 branch was created.

          I thought I remembered a discussion on a vote thread for 4.3 about a fix for a multi-part mime issue that went into one of the later release candidates, but now I can't find it, so it must have happened only in my mind. I double-checked the 4.3 code branch and this is NOT included.

          I believe that it's now too late to get it into 4.3. You have the option of building branch_4x if you need the fix now.

          Show
          Shawn Heisey added a comment - Karl Wright It has been committed into trunk (5.0) and branch_4x (4.4). The commits happened on April 19th, which is after the 4.3 branch was created. I thought I remembered a discussion on a vote thread for 4.3 about a fix for a multi-part mime issue that went into one of the later release candidates, but now I can't find it, so it must have happened only in my mind. I double-checked the 4.3 code branch and this is NOT included. I believe that it's now too late to get it into 4.3. You have the option of building branch_4x if you need the fix now.
          Hide
          Furkan KAMACI added a comment -

          This has been committed into 4.3 (http://lucene.apache.org/solr/4_3_0/changes/Changes.html#4.3.0.new_features) We can change fix version/s of this issue.

          Show
          Furkan KAMACI added a comment - This has been committed into 4.3 ( http://lucene.apache.org/solr/4_3_0/changes/Changes.html#4.3.0.new_features ) We can change fix version/s of this issue.
          Hide
          Shawn Heisey added a comment -

          Furkan KAMACI I've checked the 4.3.0 source and this patch did not make it in there.

          Looking through the commit history and the issue notes, what happened is this: An initial patch was created and committed on April 16th. That commit included the entry in CHANGES.txt. It was quickly discovered that this didn't fix the issue, so the code change was reverted - but the entry in CHANGES.txt got left behind. The 4.3 code branch was created on April 17th. On April 19th, the true fix for this issue was committed to trunk and the 4x branch.

          The CHANGES.txt for 4.3.0 is unfortunately wrong - the fix is NOT in 4.3.

          Show
          Shawn Heisey added a comment - Furkan KAMACI I've checked the 4.3.0 source and this patch did not make it in there. Looking through the commit history and the issue notes, what happened is this: An initial patch was created and committed on April 16th. That commit included the entry in CHANGES.txt. It was quickly discovered that this didn't fix the issue, so the code change was reverted - but the entry in CHANGES.txt got left behind. The 4.3 code branch was created on April 17th. On April 19th, the true fix for this issue was committed to trunk and the 4x branch. The CHANGES.txt for 4.3.0 is unfortunately wrong - the fix is NOT in 4.3.
          Hide
          Steve Rowe added a comment -

          Bulk close resolved 4.4 issues

          Show
          Steve Rowe added a comment - Bulk close resolved 4.4 issues

            People

            • Assignee:
              Ryan McKinley
              Reporter:
              Karl Wright
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development