Hello, I suppose that this ticket is the same than #154.

Can you try after changing the following:

return {result: ZOO.SERVICE_SUCCEEDED, outputs: [ {name:"Result", value: long} ] };

By this:

return {result: ZOO.SERVICE_SUCCEEDED, outputs: {"Result":{ value: long } }  };

Thanks. That helped.

When I execute the service such as the following it works.

./zoo_loader.cgi 'ServiceProvider??=&metapath=&Service=WPS&Request=Execute&Version=1.0.0&Identifier=javascript.chaining.testChainJS&DataInputs??=name=smith

However, when I execute through a web server such as nginx I get the following error:

[error] 29440#0: *35 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "POST /cgi-bin/zoo_loader.cgi HTTP/1.1", upstream: "​fastcgi://unix:/var/run/fcgiwrap.socket", host: "localhost"

When I use service using localhost and identifier (javascript.test.hello-world.hellojs) via web server directly (without going through chaining service) it works fine.

It doesn't like users accessing the service via a web server when the chaining process host is localhost.

I am not sure to understand your last comment. There should not be a problem to use any hostname to access the ZOO-Kernel until your web server is able to communicate with the target host.

Are you able to test on your end using a similar simple example as I've done? What web server are you using? Apache?

I use Apache, but it should not make any difference here I suppose.

Hi there. You are right. We created a VM through puppet which set ups the environment. It works etc. However, we encounter the same issue even when using apache. I'm not sure where the problem is originating from. I'm hoping you can help out. Are you able to test on your end if you are also encountering the same issue as it seems I've followed instructions but still receiving the same error message? Thanks.

Sorry for so late reply, I was attending the FOSS4G-Europe last week and was not able to come back to you earlier.

When you has submitted this ticket I have tried the scenario you have provided, it was the reason why I can fix the issue. Still I don't get the final issue, meaning that I am not able to reproduce the issue on my side. Maybe you can provide more details that may help me to understand better what happened. One thing that may be causing the issue is if you have tried to use from the command line, and it implies cache file creation, then when running from the web server, the user privileges may differ, meaning that your web server user is not allowed to read some files created by the previous execution from the command line.

Still, if you can give more details I hope I can help.

Thanks for your response. Where are the cache files created so I can delete them? Thanks.

Replying to surf09:

Thanks for your response. Where are the cache files created so I can delete them? Thanks.

The cache files depend on the main.cfg file content. In case you have a cacheDir variable defined in the [main] section it means that the cache files will be located in this directory. In other case it should use the value of the tmpPath variable to store the cache files.

I hope this helps.

Hi. After re-testing switching to Apache instead of using Nginx resolved my issue. Thanks for your help.