[
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: [email protected]
For additional commands, e-mail: [email protected]
