Christian,

I will explore those questions.

I did more work with prof:dump()—that seems to be the most effective way to narrow the point at which the problem starts.

Based on that work it appears I may be causing problems by trying to load large numbers of nodes using db:open-id(). Based on that I probably need to just rethink how I’m doing this particular process now that I have a better understand of how best to do things.

I also found putting a debugger break point on prof:dump() itself was useful—it at least lets me see where I am in the running code from within the debugger.

Cheers,

E.

_____________________________________________

Eliot Kimber

Sr Staff Content Engineer

O: 512 554 9368

M: 512 554 9368

servicenow.com

LinkedIn | Twitter | YouTube | Facebook

From: Christian Grün <christian.gruen@gmail.com>
Date: Thursday, March 3, 2022 at 1:39 AM
To: Eliot Kimber <eliot.kimber@servicenow.com>
Cc: basex-talk@mailman.uni-konstanz.de <basex-talk@mailman.uni-konstanz.de>
Subject: Re: [basex-talk] How Best to Determine What BaseX Is Doing When It Pegs the Processor?

[External Email]


Hi Eliot,

It’s hard to judge if the freeze-up is due to the query, RESTXQ or
your general configuration. Let me see…

• Do you get the full result if you invoke the query in the GUI or on
command line? How long does that take/how large is the result?
• How do you send the HTTP request? Does it make a difference if you
use the browser or cURL/Wget?
• You could check if the execution time of your request is included in
the database logs (e.g. via the DBA interface). If yes, the problem
must occur after the actual query execution.
• Do you get the execution time shown if you wrap your RESTXQ function
body with prof:time?

Feel free to share a minimized example of the RESTXQ entry point with
us (including the annotations you use).

Cheers (pun intended),
Christian


On Wed, Mar 2, 2022 at 4:35 PM Eliot Kimber <eliot.kimber@servicenow.com> wrote:
>
> I have a RESTXQ page that makes a query call to construct a report and then displays it. When I run this page something is triggering BaseX to peg the processor and it basically never returns from whatever it is doing.
>
>
>
> Using proc:dump() I can see that the call to construct the report runs and returns the expected value—this takes about 3 seconds, and then the page never returns and top shows that the java process for the BaseX HTTP server is pegged at 100%.
>
>
>
> The behavior is consistent so I know it must be something I’m doing or the effect of some configuration setting I have but no idea what might be going on. I get the behavior both on my development machine and on my production server, so it must be something in my code or some reproducible issue with the databases I’m managing.
>
>
>
> I’ve tried connecting the BaseX HTTP server to the Eclipse debugger, which works, but I’m not sure where I should be focusing my attention in the code.
>
>
>
> Turning on the -d flag isn’t that helpful either as the log is flooded with exceptions from BaseX trying to load Java classes for my XQuery modules, which swamps any more detailed debugging log messages and what messages I see appear to be entirely about the HTTP interaction, not what’s happening in the core BaseX server.
>
>
>
> Is there a particular place in the code I can focus on in the interactive debugger that would be a likely source of the behavior or another debugging technique I haven’t considered?
>
>
>
> Thanks,
>
>
>
> E.
>
> _____________________________________________
>
> Eliot Kimber
>
> Sr Staff Content Engineer
>
> O: 512 554 9368
>
> M: 512 554 9368
>
> servicenow.com
>
> LinkedIn | Twitter | YouTube | Facebook