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
