It's doing exactly what you tell it to: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7666 -jar start.jar
Specifically suspend=y' means it will sit there, very patiently, until you connect to it with a debugger and tell it to go. This is _very_ useful to debug initialization errors, but can sometimes be a bit puzzling. I'd recommend you actually attach with the debugger (i.e. a "remote" session). In IntelliJ, (I'm sure there are analogous ways in Eclipse), you create, quite literally, a "remote session" that you give the URL of the server you started above and the port. You start your server as above and then start your remote session in your IDE and you'll be in the debugger, attached to the running Solr instance. You can set breakpoints or just hit the "go" button and the server should start up. My setup usually just has "localhost" and 7666 for the URL/port. You do not have to attach a debugger first, just specify 'suspend=n' instead. But starting with 'suspend=y' insures you have actually attached to the server and have all the parts in place. Best, Erick On Sun, Sep 21, 2014 at 3:51 AM, Anurag Sharma <anura...@gmail.com> wrote: > Hi All, > > Thanks a lot for your suggestions. Shalin, your direction quickly took me > to the issue, it was very insightful and helpful. > Finally am able to understand the issue I was working on and run particular > unit test class AtomicUpdatesTest around it. > > On running the Solr in debug mode, I am still not able to start solr in > debug mode using: > java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7666 > -jar start.jar > (Ref: http://wiki.apache.org/solr/HowToConfigureEclipse) > The command wait for hours and the server never comes up on windows without > giving any error/info message. > > Please suggest if someone faced this issue. I tried restarting windows, > ensured no process running on 7666 port. In previous trials to start, I > used to get msg "Debugger failed to attach: handshake failed - received >>GET /solr/ HTT< - expect" but it stopped coming now. > > Thanks > Anurag > > > > > On Fri, Sep 19, 2014 at 8:21 PM, Erick Erickson <erickerick...@gmail.com> > wrote: > >> Yeah, it's usually pretty daunting to know where to start, the >> codebase is kinda big. Even "start from junit test" is often daunting, >> there are a lot of them too. >> >> Others have given you good places to start, good luck! >> >> Erick >> >> On Fri, Sep 19, 2014 at 12:23 AM, Bernd Fehling >> <bernd.fehl...@uni-bielefeld.de> wrote: >> > Just start at the UpdateHandler and follow it down the line. >> > >> > I would start at org/apache/solr/update/UpdateHandler.java >> > >> > If you already know if it is add, delete or update then start with >> > AddUpdateCommand.java, DeleteUpdateCommand.java or UpdateCommand.java. >> > >> > Just follow the red line :-) >> > >> > Regards >> > Bernd >> > >> > >> > Am 19.09.2014 um 08:47 schrieb Anurag Sharma: >> >> Thanks Bernd for your insight. >> >> As of now, I am focussing to fix the issue in the updater but not able >> to >> >> localize which code to look in for it. >> >> >> >> Regards, >> >> Anurag >> >> >> >> On Fri, Sep 19, 2014 at 12:09 PM, Bernd Fehling < >> >> bernd.fehl...@uni-bielefeld.de> wrote: >> >> >> >>> It depends on what you are going to do. >> >>> >> >>> If you are adding/modifying code and Junit tests use Junit test cases. >> >>> If you are debugging runtime problems under load use remote debugging. >> >>> If you are going for in deep debugging (even into Jetty and Java) use >> >>> RunJettyRun for Eclipse. >> >>> >> >>> Regards >> >>> Bernd >> >>> >> >>> >> >>> Am 18.09.2014 um 20:50 schrieb Anurag Sharma: >> >>>> Dear Solr users, >> >>>> >> >>>> I am new to Solr dev community and trying to setup eclipse to debug a >> >>>> running solr server. Please suggest if anyone of you have tried doing >> the >> >>>> same. >> >>>> >> >>>> Once above is done. Also suggest the entry point in code where >> breakpoint >> >>>> can be placed. >> >>>> >> >>>> Thanks >> >>>> Anurag >> >>>> >> >>> >> >>> >> >> >>
