<div class="gmail_quote">On Thu, Feb 2, 2012 at 3:49 PM, Robert Zermeno <span dir="ltr"><<a href="mailto:refriguy68@yahoo.com">refriguy68@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font:inherit" valign="top"><div>I am trying to stream JPIPs. I have two threads that are accessing the same file using the same GDALfiledataset. One thread is a subsample image used as a navigator and the other thread is the full-sized image for the viewer to see the full image.</div>
<div> </div>
<div>Each thread uses its own GDALAsyncReaderH Object. Each thread detects if the AsyncReader object is not NULL prior to calling GDALBeginAsyncReader(). If either AsyncReader is not NULL, then call GDALEndAsyncReader(). Sounds good right?</div>
<div> </div>
<div>Has anyone experienced the issue of GDALEndAsyncReader() taking longer than 10-20 seconds to return? Can someone explain to me why it might take that long just to delete the AsyncReader object for JPIP to be able to process my next wanted region?</div>
<div> </div>
<div>I hope that makes since for anyone to answer my quest. If not, let me know as I can provide more information. I am currently using the repository build from 2-1-2012</div>
<div> <br clear="all"></div></td></tr></tbody></table></blockquote></div><br>Bob,<br><br>The JPIP driver implementation is a bit messy and I suspect<br>much more complicated than it really needs to be. Looking<br>at the JPIPKAKAsyncReader::Stop() method it seems there is<br>
interaction with a global mutex (global to the dataset that is), and<br>then potentially waiting for the work thread to report back that it<br>is complete. It is not immediately obvious to me why this would <br>take a long time. <br>
<br>It looks like the Stop() function effectively sets one<br>of bHighThreadRunning or bLowThreadRunning to FALSE<br>as an indicator that the JPIPWorkerFunc() should stop after<br>it has finished processing it's next chunk from the server. <br>
Depending on chunk size and latency this might be a while<br>I suppose. In theory we might be able to make the <br>JPIPWorkerFunc() do more fine grained checking - for<br>instance between reading of data by http and processing<br>
it via the jpeg2000 ReadFromInput() method. <br><br>I'd suggest turning on debug output (eg. CPL_DEBUG=ON)<br>and add some debug output in JPIPWorkerFunc to see if it<br>is holding things up. Possibly it is also some problem getting<br>
one of the mutexes. I didn't normally have more than one<br>async request at a time so there could be some fails in <br>the periods over which the mutexes are held. <br><br>Patches welcome!<br><br>Best regards,<br>-- <br>
---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | <a href="http://pobox.com/%7Ewarmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>
and watch the world go round - Rush | Geospatial Software Developer<br><br>