[
https://issues.apache.org/jira/browse/SOLR-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14903:
--------------------------------------
Attachment: SOLR-14903.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
I'm attaching a straw man approach, inspired by the way start.jar works.
The basic idea is a "JettyManager" that uses jetty's {{XmlConfiguration}} class
to "configure" jetty objects found in the {{server/etc/*.xml}} files, with some
minor tweaks using jetty {{<Property/>}} xml nodes to read from a
{{Properties}} object passed to the {{XmlConfiguration}} instead of directly
from system properties (and to prevent the "normal" solr webapp loading)
Once jetty is up on a random port, *THEN* we make things like the {{hostPort}}
available to the {{WebAppContext}} for Solr via the existing hooks in
{{SolrDispatchFilter}}
There are still some gaps that seem eaisly filled (like SSL and populating the
SSL properties using randomzed SSL config) but at the moment things look really
promising -- i'm pretty sure we can refactor the "JettyManager" code i've got
here to be a test-framework subclass of {{JettySolrRunner}}, implimeneting it's
full API (allthough i think we should intentionally ignore the "re-use same
port" option for the {{start()}} method -- it makes no sense in tests).
Currently the biggest problem i haven't figured out is a very werid error in my
test: something about the way the test is written seems to be causing the
IndexWriter to be ephemeral and never write to disk -- so stoping and
restarting a jetty intsance results in an empty index -- no idea why (maybe
DUH2 is picking up the wrong dataDir? ... but the tlog files are showing up in
the right place ... like i said it's weird).
I'm about to go offline for ~12 days, but I plan to pick this back up when i
return ... i welcome any feedback or concerns on the approach i'm currently
headed.
----
BTW: Another example of how our test infra is lying to us that i discovered
while working on this: we have test confirming the gzip encoded responses work
if the client requests them -- but that only works using JettySolrRunner,
because the *real* solr server doesn't have it configured: SOLR-11752
> SolrCloud tests should use the jetty.xml that we ship with
> ----------------------------------------------------------
>
> Key: SOLR-14903
> URL: https://issues.apache.org/jira/browse/SOLR-14903
> Project: Solr
> Issue Type: Improvement
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-14903.patch
>
>
> writing a good test for SOLR-14898 turned out to be a challenge because
> SolrCloudTestCase -- and any test using jetty -- doesn't _actually_ use the
> jetty.xml that real Solr nodes use, because JettySolrRunner manually
> configures i'ts jetty "Server" instance.
> We should fix this so what you get i na test matches what a real Solr node
> does.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
