[
https://issues.apache.org/jira/browse/LUCENE-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425761#comment-13425761
]
Erick Erickson commented on LUCENE-4276:
----------------------------------------
IMO, we _must_ provide the ability to override. Changing the JVM is not trivial
in some organizations for a variety of reasons, from "policy" to worry about
whether version X is compatible with all the _other_ apps (yeah, I know you can
run multiple JVMs, but we're talking corporate policy here) to only using
certified JVMs. Making this non-overridable would lock Solr/Lucene out of
running in some organizations.
The other issue is that now a new user may not be able to even take Solr/Lucene
for a test drive very easily. Imagine you're coming to Solr just to give it a
spin and you can't get it to run without changing your JVM. That would be one
more barrier to people using it. One of the strengths of Solr/Lucene is all the
hoops you _don't_ have to jump through to run the example code.
That said, I _also_ agree it's just asking for trouble to run with known JVMs
that can produce corrupt indexes. We should make it harder to do this naively.
The current setup makes it easy to run with a JVM that can assassinate you down
the road. Like after you've gone to production. And your commercial site is
costing you $$$/second as long as it's down. That's, uhhhmmmm, bad.
It's also a time sink, I'd like to head using known buggy JVMs off at the pass.
I also like the fact that we'd have a concise, known place to go to see all the
JVMs that have known problems. It gives us a nice place to point users at when
they see problems ("Is your JVM listed in known_bad_jvms.txt?"), assuming we
keep this in an external file. Hmmm would be a nice thing to keep on the Wiki
too... In big bold red letters.
So, +1 to making it harder to run with bad JVMs: If the user really wants to
blow their leg off, let them run with known bad JVMs by providing a
command-line override. I'll propose
-Dit.is.stupid.to.run.with.a.known.buggy.JVM.but.we.will.do.it.anyway=true. Or
perhaps
-DI.really.hate.the.execs.so.we.will.devalue.stock.options=true.
I'd really like to have a way to require the _name_ of the person making the
decision to override in all the startup scripts they'd have that implemented
the override, but that's just being mean....
-1 to making it impossible to run with a bad JVM
+1 to being really terse with users who override things and complain anyway.
> refuse to execute on broken corrupting jvms
> -------------------------------------------
>
> Key: LUCENE-4276
> URL: https://issues.apache.org/jira/browse/LUCENE-4276
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Robert Muir
> Priority: Blocker
> Fix For: 4.0
>
> Attachments: LUCENE-4276.patch
>
>
> There are some jvms where we know lucene does not work at all and will just
> produce things like corrupt indexes.
> We should detect this in a static block of Constants.java and refuse to run
> at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
