NP, glad to help someone dig into the Solr code.
We'll wait for the patch ;)...
Erick
On Sun, Sep 21, 2014 at 8:52 PM, Anurag Sharma wrote:
> Hey Eric,
>
> It works like charm :).
> Thanks a lot for pin pointing the issue. My bad I was using the suspend=y
> option blindly.
>
> Thanks again,
> A
Hey Eric,
It works like charm :).
Thanks a lot for pin pointing the issue. My bad I was using the suspend=y
option blindly.
Thanks again,
Anurag
On Sun, Sep 21, 2014 at 10:03 PM, Erick Erickson
wrote:
> It's doing exactly what you tell it to:
>
> java -Xdebug -Xrunjdwp:transport=dt_socket,serv
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 initializati
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 stil
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
wrote:
> Just start at
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
You need to look at DistributedUpdateProcessor and specifically the
getUpdatedDocument method.
On Fri, Sep 19, 2014 at 12:17 PM, Anurag Sharma wrote:
> 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
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.
>
> I
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
Hi Erick,
Thanks a lot for your response.
I am trying to fix the issue:
https://issues.apache.org/jira/browse/SOLR-6307. I guess this require
change in the 'update' component. Am not able to locate the code for
'update' component nor the testcases.
To understand the code base I think I may need
There are two approaches that work:
1> (preferred IMO) is to debug through the Junit test cases. It's far
easier than remote debugging usually, with quicker turnaround times.
2> Set up remote debugging, see:
http://wiki.apache.org/solr/HowToConfigureEclipse which is linked from
the "how to contrib
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
12 matches
Mail list logo
