On 2/4/2015 3:48 AM, Jan Høydahl wrote: > Until 5.x Solr would start on whatever port of the appserver chosen, i.e. > 8983 for Jetty, 8080 for Tomcat etc. > Now that Solr is a "standalone" app, why should we "inherit" Jetty's default > port 8983 anymore? > > So I propose we pick a brand new port number for Solr to use as default. > Benefits: > * Identity - people will immediately identify Solr by its port number. Even > IANA? > * Less risk of clash with existing Jetty service on the same server > * We could pick a cleaner port which is not 6 syllables to pronounce :) > > PS: Same goes for the default URL. We could move to toplevel now > http://localhost:8983/ > > I realize both of these will break a lot of docs and tools assuming where > stuff is, > but it has always been configurable anyway, so it's not a contract we have > promised to stick to.
Pedantic point -- Solr is not yet a standalone app. It's still using jetty, and most likely a war. Even when it DOES become a standalone app (which I hope can be soon), I see no reason to change the default port number. For the end user, it must always be easy to change the port number if they wish. If we can get an official port number assignment from IANA, and it's not 8983, then that would be a good reason to change the default port. I don't know what would be involved in getting an official assignment. It would be good to avoid the problems encountered when the initial port for RADIUS was found to already be assigned. Currently 8983 is not officially assigned, so hopefully we wouldn't run into that pain. I also don't see any strong reason to eliminate /solr as a default URL path. It might be easy to do, and even somewhat logical given that a standalone app won't be serving any additional paths, but it will require changes to almost all existing user code and large amounts of official and unofficial documentation, with no definable advantage that I can see. It might also result in less capability (or a more complicated configuration) for proxy servers talking to Solr. If a strong technical argument is put forth for moving to the / path, I'm willing to reconsider my opinion. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
