New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OGR outputs fail in fastcgi mode when STORAGE is set to stream #4858

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@tbonfort
Member

tbonfort commented Jan 31, 2014

When setting FORMATOPTION "STORAGE=stream" in an OGR outputformat, all fastcgi requests for that format will result in a 0 length response. This seems reasonable as the /vsistdout/ datasource is not connected to the fastcgi msIO.

cc @rouault . is there a workaround to use msIO* functions in OGR? Would there be any reason to not switch to a memory storage if we can detect we are run in an fcgi container?

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Jan 30, 2014

Contributor

There's currently no way (that I can imagine of) of using msIO* in OGR. But I can imagine that the CPL library in GDAL could be extended to accept user provided callbacks, that MapServer would set with its msIO functions.

Using memory storage is an alternative if the output fits in RAM. /vsistdout/ has the advantage to be a streaming mode.

Contributor

rouault commented Jan 30, 2014

There's currently no way (that I can imagine of) of using msIO* in OGR. But I can imagine that the CPL library in GDAL could be extended to accept user provided callbacks, that MapServer would set with its msIO functions.

Using memory storage is an alternative if the output fits in RAM. /vsistdout/ has the advantage to be a streaming mode.

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Jan 31, 2014

Member

I suspect the streaming mode will also fail if used through mapscript when the msIO functions have been configured to output to a buffer. I'll try to cook a workaround for this ...

Member

tbonfort commented Jan 31, 2014

I suspect the streaming mode will also fail if used through mapscript when the msIO functions have been configured to output to a buffer. I'll try to cook a workaround for this ...

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Jan 31, 2014

Member

@rouault @szekerest could you have a look at the proposed fix ?

Member

tbonfort commented Jan 31, 2014

@rouault @szekerest could you have a look at the proposed fix ?

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Jan 31, 2014

Contributor

Looks good to me. At some point, I should try to find a way for mapserver to plug its msIO functions to be used by the vsistdout virtual file system.

Contributor

rouault commented Jan 31, 2014

Looks good to me. At some point, I should try to find a way for mapserver to plug its msIO functions to be used by the vsistdout virtual file system.

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Mar 7, 2014

Member

applied for 6.4.2 in 3d174b4

Member

tbonfort commented Mar 7, 2014

applied for 6.4.2 in 3d174b4

@tbonfort tbonfort closed this Mar 7, 2014

zidge added a commit to mapsherpa/mapserver that referenced this pull request Mar 10, 2014

pagameba added a commit to mapsherpa/mapserver that referenced this pull request May 27, 2014

kwrobot pushed a commit to aashish24/gdal-svn that referenced this pull request May 30, 2014

pagameba added a commit to mapsherpa/mapserver that referenced this pull request Sep 30, 2014

samalone pushed a commit to samalone/gdal-ios that referenced this pull request Oct 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment