The problem was that the source files of the virtual dataset were not
readable by the process that was running the web server in multi worker
mode (production mode) while I was running it myself in the debug mode
(single worker mode). The .vrt file was readable by all.
The virtual dataset did return an error code but I did not even get to
the point in my debugging where I could see from the code that it was a
simple not allowed to open those files - it was so deep. I could not see
the error message although I tried, it was lost at some point. I'll try
to understand why.
Best,
Ari
On 14.11.2015 18:59, Even Rouault wrote:
Le samedi 14 novembre 2015 17:46:47, Ari Jolma a écrit :
I'm using the Translate function to clip tiles from a larger raster
using Perl bindings. I'm clipping into PNG files.
This is in a web service environment, i.e., several workers listening to
a client.
Ari,
Are the workers multi-threaded or each in their own process ?
But even in the multi-threaded case, I can't reproduce with the following :
#include "cpl_multiproc.h"
#include "gdal_utils.h"
#include "gdal.h"
void copyFunc(void* arg)
{
const char* pszOut = (const char*)arg;
GDALDatasetH hSrcDS = GDALOpen("byte.tif", GA_ReadOnly);
char* argv[] = { "-of", "PNG", NULL };
GDALTranslateOptions* psOptions = GDALTranslateOptionsNew(argv, NULL);
GDALClose(GDALTranslate(pszOut, hSrcDS, psOptions, NULL));
GDALClose(hSrcDS);
GDALTranslateOptionsFree(psOptions);
}
int main(int argc, char* argv[])
{
CPLJoinableThread *ht1, *ht2;
GDALAllRegister();
while(1)
{
ht1 = CPLCreateJoinableThread(copyFunc, "test1.png");
ht2 = CPLCreateJoinableThread(copyFunc, "test2.png");
CPLJoinThread(ht1);
CPLJoinThread(ht2);
}
}
I assume your GDAL is built --with-threads (which is the default) if you use
it in a multi-threaded context.
Even
The Translate fails in pngwrite.c, in png_write_end with error
"No IDATs written into file".
The script works fine when I have only one worker.
I have tried writing the file into file system, VSI file system, etc.
The error is the same. The output seems to be consistently 33 bytes
long, i.e., only the header I guess.
I'm using unique file names.
Any ideas?
Ari
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
