You can clone with
HTTPS or Subversion.
This bug applies to version 1.3.3 when run in Windows.
I noticed this issue when trying to run rack sunspot:solr:run. It seemed that even though I was in a development environment in Rails, the server wouldn't start on any port other than 8983. I narrowed the problem down to the following call on line 112 in server.rb in sunspot\solr:
The shelljoin function escapes the equals signs in the arguments to do things like setting the port. When called with Ruby's exec call, the shell used is taken from the environment variable RUBYSHELL or COMSPEC. In my case, COMSPEC was set to the Windows' cmd.exe. The escape sequences screw up the command options in cmd.exe and thus the port option is not set properly.
It's easy to test this by running start.jar manually from the Windows command prompt and trying:
java -Djetty.port=8982 -jar start.jar -- this works and starts the server on port 8982
java -Djetty.port\=8982 -jar start.jar -- this doesn't work and starts the server on port 8983
java -Djetty.port=8982 -jar start.jar
java -Djetty.port\=8982 -jar start.jar
I'm not sure what the solution is. Perhaps setting RUBYSHELL to be /bin/sh would solve the problem, but it would be nice if the command that's executed worked in multiple shells.
For 2.0 I'd really prefer to see a multicore setup, making all this port juggling a thing of the past. See #115.
This issue appears to be fixed by this commit: 695aa9c
Making that change to my code makes the command start correctly in a Windows shell. Are there any versions being released soon that would include this change?
We've released 2.0 which should include that commit.