I found that it is locking up because of the database global lock<http://docs.basex.org/wiki/Options#GLOBALLOCK> which locks during any updating function. On the long updating call that was happening first, it was grabbing the lock and so every subsequent request was being blocked until the update had finished. I think the solution for us is to turn it off since we're never updating any content in place, only adding content, and that content is static so it doesn't matter if two requests clobber the data.
On Wed, Sep 25, 2013 at 9:30 AM, France Baril <france.ba...@architextus.com>wrote: > I'm having similar issues where everything freezes on an http request done > from inside a restxq function, but only if certain conditions are present. > > The conditions are not easy to pinpoint. However, they affect our ability > to validate content against modular dtds/xsds, to apply modular .xsl and > .xsl that were grabbing pieces of content with doc(restxq...) accesses, and > to create PDF with a FOP module because the fo references images stored as > raw files and only accessible by http://..rest/ paths. > > I'm in the 3rd week of refactoring our application so we can migrate to > 7.7. I believe I am half way there. The main task is to augment content > through query before the document is sent to .xsl to remove all needs for > the use of the doc(restxq) functions. We also find that we can no longer > have a self-contained application and that we have to create new steps to > export pieces of content and applicative files to the file system. > > Not having a self-contained application is a huge step back for us where > we have to start considering that different OS handle different paths > differently. For example, Windows is killing our capitalization on content > re-import which multiplies the folder structures (looks like we'll need to > naming conventions). > > I'm hoping someone can provide a case simple enough to be submitted and > that will help pinpoint the exact source of the problem and resolve the > issue. Our refactoring for doc(restxq) will be done by there, but not > having to export applicative files and images for processing would bring us > back to a neat/clean self-contained application. > > Regards, > > France > > > > On Fri, Sep 20, 2013 at 6:13 PM, Joe Templeman <j...@inkling.com> wrote: > >> Hi all, >> >> I'm having trouble with the running a restxq API, set up as either a >> stand alone app (using basexhttp) or running the servlet in jetty. >> >> When I make a request, the server will lazily load in the requested >> content using a small java library that I've built which can take quite a >> while, and unfortunately it completely blocks waiting for this request to >> complete. This means that if I make a request for content which is already >> loaded, which should return in a couple of milliseconds, it instead waits >> for the downloading of the first request to complete before returning. >> >> I'm sure it's something simple that I'm missing in the config somewhere, >> but I have the threadpool parameters set up in my jetty.xml config file but >> it doesn't seem to make any difference. >> >> Is this expected behavior? I can't imagine any HTTP server would ever be >> designed to be single threaded... >> >> Any help is welcome, I've been trying to figure this out for days now. >> >> Thanks, >> Joe >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk@mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> > > > -- > France Baril > Architecte documentaire / Documentation architect > france.ba...@architextus.com > (514) 572-0341 >
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
