lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-4136) SolrCloud bugs when servlet context contains "/" or "_"
Date Tue, 11 Dec 2012 19:47:21 GMT

     [ https://issues.apache.org/jira/browse/SOLR-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated SOLR-4136:
---------------------------

    Attachment: SOLR-4136.patch

ok, so it turns out the failure i was seeing scroll by all came from OverseerCollectionProcessorTest
which is a new test added in SOLR-4114.

The assertion failure(s) are fairly obtuse...

{noformat}
      <failure message="
  Expectation failure on verify:
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0
    takeCompletedOrError(): expected: 7, actual: 0
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0
    submit(capture(Nothing captured yet), capture(Nothing captured yet), capture(Nothing captured
yet)): expected: 1, actual: 0" type="java.lang.AssertionError"
{noformat}

...but the root issue seems to be hidden in a log message i found: the easymock stuff is evidently
freaking out because a new method is being called that it doesn't expect...

{noformat}
[junit4:junit4]   2> 689 T1552 oasc.SolrException.log SEVERE Collection createcollection
of mycollection failed:java.lang.AssertionError: 
[junit4:junit4]   2> 	  Unexpected method call getZkClient():
[junit4:junit4]   2> 		at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:45)
[junit4:junit4]   2> 		at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:73)
[junit4:junit4]   2> 		at org.easymock.internal.ClassProxyFactory$MockMethodInterceptor.intercept(ClassProxyFactory.java:92)
[junit4:junit4]   2> 		at org.apache.solr.common.cloud.ZkStateReader$$EnhancerByCGLIB$$a53a0cdb.getZkClient(<generated>)
[junit4:junit4]   2> 		at org.apache.solr.cloud.OverseerCollectionProcessor.createCollection(OverseerCollectionProcessor.java:263)
[junit4:junit4]   2> 		at org.apache.solr.cloud.OverseerCollectionProcessor.processMessage(OverseerCollectionProcessor.java:155)
[junit4:junit4]   2> 		at org.apache.solr.cloud.OverseerCollectionProcessor.run(OverseerCollectionProcessor.java:102)
[junit4:junit4]   2> 		at java.lang.Thread.run(Thread.java:679)
[junit4:junit4]   2> 	
{noformat}

The new test also has some hardcoded assumptions about hte context being "solr" and being
able to rebuild the URL by replacing "_" with "/" -- but since it doesn't subclass the distrib
base test, i think those will actualy be ok.  i just need help udnerstanding how to tell the
easy mock stuff to expect this method call.

---

The updated attachment:

1) brings things up to date with trunk
2) incorporated my jetty context change suggestion from SOLR-4057 so it's really trivial now
to run the example on any context you want
3) fixes a small glitch in the generated the "baseUrl" for a node when context is "/" ...
the trailing "/" was being left on the URL, which is inconsistent with past behavior, so i
cleaned that up (this was triggering a failure in CloudSolrServerTest because it was finding
that "http://foo:8983//collection1" wasn't equal to "http://foo:8983/collection1" when checking
the leader URL)

...but it still suffers from the easy mock failure.



                
> SolrCloud bugs when servlet context contains "/" or "_"
> -------------------------------------------------------
>
>                 Key: SOLR-4136
>                 URL: https://issues.apache.org/jira/browse/SOLR-4136
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 4.0
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>         Attachments: SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch,
SOLR-4136.patch
>
>
> SolrCloud does not work properly with non-trivial values for "hostContext" (ie: the servlet
context path).  In particular...
> * Using a hostContext containing a  "/" (ie: a servlet context with a subdir path, semi-common
among people who organize webapps hierarchically for lod blanacer rules) is explicitly forbidden
in ZkController because of how the hostContext is used to build a ZK nodeName
> * Using a hostContext containing a "\_" causes problems in OverseerCollectionProcessor
where it assumes all "\_" characters should be converted to "/" to reconstitute a URL from
nodeName (NOTE: this code specifically has a TODO to fix this, and then has a subsequent TODO
about assuming "http://" labeled "this sucks")

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message