[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Mon Jul 21 16:36:58 EDT 2014
Got it. Rebuilding Apache now.
Thanks!
On Mon, Jul 21, 2014 at 3:29 PM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
> You must have Apache 2.4.7+
> Their is a fix in that version which allow mod_rewrite to work on web
> socket protocol instead of just http.
> You can look at the apache section in here
> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/paraviewweb_on_aws_ec2
>
> Seb
>
>
> On Mon, Jul 21, 2014 at 2:25 PM, Dmitry Duplyakin <duplyakin at uchicago.edu>
> wrote:
>
>> We are running Apache/2.2.22 with loaded proxy_wstunnel_module (that we
>> had to build from source).
>>
>> From Apache error log (with debug):
>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy_http.c(56): proxy: HTTP:
>> canonicalising URL //localhost:8080/paraview/
>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(1506): [client
>> 130.202.2.217] proxy: http: found worker http://localhost:8080/paraview
>> for http://localhost:8080/paraview/, referer:
>> http://54.211.22.94/apps/Cone/
>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy.c(1020): Running scheme http
>> handler (attempt 0)
>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy_http.c(1973): proxy: HTTP:
>> serving URL http://localhost:8080/paraview/
>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2011): proxy: HTTP: has
>> acquired connection for (localhost)
>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2067): proxy: connecting
>> http://localhost:8080/paraview/ to localhost:8080
>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2193): proxy: connected
>> /paraview/ to localhost:8080
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1743): proxy: start
>> body send
>> [Mon Jul 21 20:20:14 2014] [debug] mod_deflate.c(615): [client
>> 130.202.2.217] Zlib: Compressed 242 to 155 : URL /paraview/, referer:
>> http://54.211.22.94/apps/Cone/
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1847): proxy: end
>> body send
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2029): proxy: HTTP: has
>> released connection for (localhost)
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(56): proxy: HTTP:
>> canonicalising URL //54.211.22.94/ws://localhost:9998/ws
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(1525): [client
>> 130.202.2.217] proxy: *: found reverse proxy worker for
>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy.c(1020): Running scheme http
>> handler (attempt 0)
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1973): proxy: HTTP:
>> serving URL
>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2011): proxy: HTTP: has
>> acquired connection for (*)
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2067): proxy: connecting
>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>> to 54.211.22.94:80
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2193): proxy: connected
>> /ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8 to
>> 54.211.22.94:80
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2444): proxy: HTTP: fam 2
>> socket created to connect to *
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2576): proxy: HTTP:
>> connection complete to 54.211.22.94:80 (54.211.22.94)
>> [Mon Jul 21 20:20:14 2014] [error] [client 54.211.22.94] File does not
>> exist: /pv/www/ws:
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1743): proxy: start
>> body send
>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1847): proxy: end
>> body send
>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2029): proxy: HTTP: has
>> released connection for (*)
>>
>>
>> POST took ~1 second. Timestamps for POST and the following GET:
>> 21/Jul/2014:20:23:02 and 21/Jul/2014:20:23:03
>>
>>
>>
>> On Mon, Jul 21, 2014 at 3:10 PM, Sebastien Jourdain <
>> sebastien.jourdain at kitware.com> wrote:
>>
>>> Which version of Apache are you using? Do you have the ws_tunnelling (<=
>>> wrong name but something like that) module enabled?
>>>
>>> You may be able to check the system log that apache generate to see what
>>> went wrong.
>>> Do you know how much time the POST request took?
>>>
>>> Seb
>>>
>>>
>>> On Mon, Jul 21, 2014 at 1:59 PM, Dmitry Duplyakin <
>>> duplyakin at uchicago.edu> wrote:
>>>
>>>> Continue troubleshooting...
>>>>
>>>> Now we get this in response to POST:
>>>>
>>>> {"updir": "/Home", "sessionManagerURL": "http://54.211.22.94:/paraview/",
>>>> "port": 9999, "host": "localhost", "sessionURL": "ws://
>>>> 54.211.22.94/proxy?sessionId=369f8648-110f-11e4-b402-22000b0185a8",
>>>> "id": "369f8648-110f-11e4-b402-22000b0185a8"}
>>>>
>>>> Looks right to me. Then, after that POST, it does GETs that do not look
>>>> right:
>>>>
>>>> 54.211.22.94 - - [21/Jul/2014:19:54:29 +0000] "GET
>>>> */ws://localhost:9999/ws?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8*
>>>> HTTP/1.1" 404 509 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
>>>> rv:30.0) Gecko/20100101 Firefox/30.0"
>>>>
>>>> 130.202.2.217 - - [21/Jul/2014:19:54:29 +0000] "GET
>>>> /proxy?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8 HTTP/1.1" 404 509 "-"
>>>> "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101
>>>> Firefox/30.0"
>>>>
>>>> And the message:
>>>>
>>>> Firefox can't establish a connection to the server at ws://
>>>> 54.211.22.94/proxy?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8.
>>>> return new WebSocket(url, protocols);
>>>>
>>>> What can possibly cause this? Again, complete apache and launcher
>>>> configs are in the previous email.
>>>>
>>>>
>>>> On Mon, Jul 21, 2014 at 2:07 PM, Dmitry Duplyakin <
>>>> duplyakin at uchicago.edu> wrote:
>>>>
>>>>> This helped tremendously!
>>>>>
>>>>> Both "-f" and "${host}" now make a lot more sense.
>>>>>
>>>>> POST works fine now and we can see the Rewrite rule in action.
>>>>> Something there still needs attention and we are investigating further.
>>>>>
>>>>> Thanks for you patience and all the help that allows us to move
>>>>> forward.
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 12:59 PM, Sebastien Jourdain <
>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> you may still have a typo
>>>>>>
>>>>>> => "ws://${host}/proxy?sessionId=${id}",
>>>>>>
>>>>>> ${host} should have been replaced with a static string that match the
>>>>>> host that the web browser is using to reach apache.
>>>>>>
>>>>>> Moreover, I forgot to mention that you need to add "-f" in your set
>>>>>> of arguments. That will force some output generation to fill some buffer
>>>>>> which will allow the launcher to detect when the server is actually ready.
>>>>>>
>>>>>> I've noticed that the documentation is missing them. Don't know
>>>>>> why... Will update it at some point.
>>>>>> Although this page show that option:
>>>>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/py_launcher
>>>>>>
>>>>>> And the value for "timeout" should be way bigger than 5. Like 25
>>>>>> maybe.
>>>>>>
>>>>>> Seb
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 21, 2014 at 10:58 AM, Dmitry Duplyakin <
>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>
>>>>>>> Thanks for this detailed description! The process is starting to
>>>>>>> make sense and we can communicate more efficiently about our configuration
>>>>>>> and problems.
>>>>>>>
>>>>>>> Here is our complete launch.json (with the right sessionURL for a
>>>>>>> config with Apache, according to your email):
>>>>>>> {
>>>>>>> "configuration": {
>>>>>>> "content": "/pv/www",
>>>>>>> "log_dir": "/pv/logs",
>>>>>>> "host": "localhost",
>>>>>>> "endpoint": "paraview",
>>>>>>> "sessionURL": "ws://${host}/proxy?sessionId=${id}",
>>>>>>> "timeout": 5,
>>>>>>> "upload_dir": "/pv/data",
>>>>>>> "fields": ["file", "host", "port", "updir"],
>>>>>>> "port": 8080,
>>>>>>> "proxy_file": "/pv/conf/proxy.conf"},
>>>>>>> "apps": {
>>>>>>> "data_prober": {"cmd": ["${python_exec}",
>>>>>>> "${python_path}/paraview/web/pv_web_data_prober.py", "--port", "${port}",
>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>> "pipeline": {"cmd": ["${python_exec}",
>>>>>>> "${python_path}/paraview/web/pv_web_visualizer.py", "--port", "${port}",
>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>> "loader": {"cmd": ["${python_exec}",
>>>>>>> "${python_path}/paraview/web/pv_web_file_loader.py", "--port", "${port}",
>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py", "--port",
>>>>>>> "${port}"], "ready_line" : "Starting factory"}},
>>>>>>> "properties": {
>>>>>>> "python_path": "/pv/paraview/lib/paraview-4.1/site-packages/",
>>>>>>> "data": "/pv/data",
>>>>>>> "python_exec": "/pv/paraview/bin/pvpython"},
>>>>>>> "resources": [{"port_range": [9901, 9999], "host": "localhost"}],
>>>>>>> "sessionData": {"updir": "/Home"}
>>>>>>> }
>>>>>>>
>>>>>>> Apache host file:
>>>>>>> <VirtualHost *:80>
>>>>>>> ServerAdmin webmaster at localhost
>>>>>>> DocumentRoot /pv/www
>>>>>>> <Directory /pv/www/>
>>>>>>> Options Indexes FollowSymLinks MultiViews
>>>>>>> AllowOverride None
>>>>>>> Order allow,deny
>>>>>>> allow from all
>>>>>>> </Directory>
>>>>>>>
>>>>>>> ProxyPass /paraview http://localhost:8080/paraview
>>>>>>>
>>>>>>> RewriteEngine On
>>>>>>> RewriteMap session-to-port txt:/pv/conf/proxy.conf
>>>>>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
>>>>>>> RewriteRule ^/proxy.*$ ws://${session-to-port:%1}/ws [P]
>>>>>>>
>>>>>>> RewriteLog "/var/log/apache2/rewrite.log"
>>>>>>> RewriteLogLevel 3
>>>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>>>>>>> LogLevel debug
>>>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>>>>>>> </VirtualHost>
>>>>>>>
>>>>>>> Now when we access http://<PVW server>/apps/Cone/ in the browser,
>>>>>>> it does POST {"sessionManagerURL":"http://<CORRECT IP FOR PVW
>>>>>>> server>:/paraview/","application":"cone"}. Then Launcher starts a process
>>>>>>> listening to a port from the range (e.g. 9999). We can see that process:
>>>>>>> ps auwx | grep cone
>>>>>>> root 27943 2.3 1.8 1015600 137664 pts/2 Sl+ 16:32 0:00
>>>>>>> /pv/paraview/lib/paraview-4.1/pvpython
>>>>>>> /pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py --port 9999
>>>>>>>
>>>>>>> After that we get a session timeout and this response: "Session did
>>>>>>> not start before timeout expired. Check session logs."
>>>>>>>
>>>>>>> Any further advice?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 21, 2014 at 10:02 AM, Sebastien Jourdain <
>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>
>>>>>>>> Hi Dmitry,
>>>>>>>>
>>>>>>>> First of all you need to understand the role of apache here in
>>>>>>>> order to see how the configuration should be.
>>>>>>>> As you may know, you can use ParaViewWeb without Apache, but such
>>>>>>>> setup is not meant for production.
>>>>>>>>
>>>>>>>> The list below is what you get when you add Apache:
>>>>>>>> - Apache can be use to serve the static content (html, js, png,
>>>>>>>> css...)
>>>>>>>> - Apache provide a single entry point host + port. This prevent
>>>>>>>> cross-domain issue or firewall limitation.
>>>>>>>> - Apache will relay the WebSocket communication to the proper
>>>>>>>> ParaViewWeb instance on the backend based on a session ID. This mean that
>>>>>>>> the ParaViewWeb process DOES NOT need to be on the same machine as the
>>>>>>>> Apache Web Server.
>>>>>>>>
>>>>>>>> Then you need to understand how the launcher works and its role.
>>>>>>>> In ParaViewWeb a launcher is used to start a new visualization
>>>>>>>> process for a given user. This simply mean running a command line with some
>>>>>>>> dynamic parameters like the port number on which this specific instance
>>>>>>>> should listen.
>>>>>>>> So when a user connect to the system and request a new
>>>>>>>> visualization session, it is the responsibility of the launcher to start
>>>>>>>> the process and let the client know on which WebSocket URL it should
>>>>>>>> connect to in order to reach the requested visualization session.
>>>>>>>>
>>>>>>>> In a setup that DOES NOT contain Apache, we can not use the same
>>>>>>>> port as the main server (the process would not start). Hence, we start it
>>>>>>>> with some port and we let the user know that it should connect to
>>>>>>>> "ws://{host}:{port}/ws" where host and port get replaced with the set that
>>>>>>>> was used to create the process.
>>>>>>>>
>>>>>>>> See section "resources" in launcher configuration.
>>>>>>>>
>>>>>>>> BUT with Apache that is different, now we have a process which is
>>>>>>>> meant to relay the communication to the backend using the port and host
>>>>>>>> that Apache is using. So the launcher should let the client know what URL
>>>>>>>> they should use so Apache could handle it and forward it to the backend.
>>>>>>>> Hence the ws://{apache_host}/proxy?sessionId=${id}.
>>>>>>>> In the same time to keep track on which host/port a process is
>>>>>>>> running the launcher generate a text file with the proper mapping.
>>>>>>>> That mapping file is then used inside Apache to figure out how it
>>>>>>>> should establish the connection to the backend.
>>>>>>>>
>>>>>>>> This should help you understand how to fix your configuration.
>>>>>>>> Moreover, here is the remaining set of questions:
>>>>>>>>
>>>>>>>> > can we specifically log and debug Rewrite rule actions?
>>>>>>>>
>>>>>>>> Don't know, Google will be your friend here...
>>>>>>>>
>>>>>>>> > do we actually need ProxyPassReverse in Apache?
>>>>>>>>
>>>>>>>> Don't know, Google will be your friend here as well as the
>>>>>>>> documentation on how to setup ParaViewWeb on Ubuntu 14LTS.
>>>>>>>>
>>>>>>>> > what particular modules in Apache are required?
>>>>>>>>
>>>>>>>> Read the documentation, the list is minimum and provided in it.
>>>>>>>>
>>>>>>>> > in launch.json there are two particular lines host/resources:
>>>>>>>>
>>>>>>>> So the "host" is to select the proper network card when you have
>>>>>>>> several for the actual launcher server.
>>>>>>>>
>>>>>>>> Then the resources are use for process management and URL
>>>>>>>> generation for the client. Which mean, what name should be used by Apache
>>>>>>>> to connect to the machine that actually run a ParaViewWeb process.
>>>>>>>>
>>>>>>>> Seb
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 21, 2014 at 8:01 AM, Dmitry Duplyakin <
>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>
>>>>>>>>> Thank you very much, Sebastien!
>>>>>>>>>
>>>>>>>>> Launcher side:
>>>>>>>>>>
>>>>>>>>>> "sessionURL": "ws://YOUR_HOST_NAME_TO_REPLACE(the one used to connect to apache)/proxy?sessionId=${id}",
>>>>>>>>>>
>>>>>>>>>> "proxy_file": "/data/proxy.txt"
>>>>>>>>>>
>>>>>>>>>> This is exactly what we have in our launcher:
>>>>>>>>>
>>>>>>>>> "sessionURL": "ws://${host}:${port}/ws",
>>>>>>>>>
>>>>>>>>> "host": "localhost",
>>>>>>>>>
>>>>>>>>> "port": 8080,
>>>>>>>>>
>>>>>>>>> Your sessionURL looks different. Do you actually use "
>>>>>>>>> proxy?sessionId=" there? Ours came directly from the script
>>>>>>>>> you've suggested earlier:
>>>>>>>>> http://www.paraview.org/gitweb?p=ParaViewSuperbuild.git;a=blob_plain;f=Scripts/pvw-setup.py;hb=HEAD
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Apache side
>>>>>>>>>>
>>>>>>>>>> RewriteMap session-to-port txt:/data/proxy.txt
>>>>>>>>>>
>>>>>>>>>> In Apache we have:
>>>>>>>>> RewriteEngine On
>>>>>>>>> RewriteMap session-to-port txt:/pv/conf/proxy.conf
>>>>>>>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
>>>>>>>>> RewriteRule ^/proxy.*$ ws://${session-to-port:%1}/ws [P]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Then when a session start you can check the content of that
>>>>>>>>>> /data/proxy.txt and that should one line by running session with
>>>>>>>>>> {sessionId} localhost:yyyyy
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Verified that those entires are added to the file and have the
>>>>>>>>> right format.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On the other hand you forgot that line in the config of your cone
>>>>>>>>>> app: "ready_line" : "Starting factory"
>>>>>>>>>>
>>>>>>>>>> Thanks! Added it and now the app looks like this:
>>>>>>>>>
>>>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py",
>>>>>>>>> "--port", "${port}"], "ready_line" : "Starting factory"}},
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> You can check is any pvpython process is running, on which port,
>>>>>>>>>> see if that match in the proxy file (/data/proxy.txt) and also looking at
>>>>>>>>>> the log directory with the output of the pvpython process.
>>>>>>>>>>
>>>>>>>>>> A common error could also be that the apache does not have the
>>>>>>>>>> right to read the /data/proxy.txt file or that the launcher is not able to
>>>>>>>>>> write it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Verified that launcher can write it and that entries are added.
>>>>>>>>>
>>>>>>>>> These are the rest of our questions (we need to sort these out
>>>>>>>>> because they have caused some confusion and we want to clear things up and
>>>>>>>>> do not come back to these issues anymore):
>>>>>>>>>
>>>>>>>>> - can we specifically log and debug Rewrite rule actions?
>>>>>>>>> - do we actually need ProxyPassReverse in Apache?
>>>>>>>>> - what particular modules in Apache are required? So far we have:
>>>>>>>>> proxy_module, proxy_http_module, and rewrite_module. We are unsure whether
>>>>>>>>> we need proxy_wstunnel_module or not.
>>>>>>>>> - in launch.json there are two particular lines:
>>>>>>>>> "host": "localhost",
>>>>>>>>> "resources": [{"port_range": [9901, 9999], "host": "localhost"}],
>>>>>>>>> where we have some confusion about using "localhost" vs.
>>>>>>>>> "0.0.0.0". What exactly should we use in either case?
>>>>>>>>>
>>>>>>>>> Appreciate your help!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Good luck,
>>>>>>>>>>
>>>>>>>>>> Seb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 20, 2014 at 10:12 AM, Dmitry Duplyakin <
>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> My name is Dmitry Duplyakin. I am a PhD student helping to build
>>>>>>>>>>> a ParaViewWeb system at University of Chicago.
>>>>>>>>>>>
>>>>>>>>>>> We are building ParaView 4.1.0 (with OSMesa) on Amazon EC2
>>>>>>>>>>> Ubuntu 12.04 instances.
>>>>>>>>>>>
>>>>>>>>>>> We have verified that PV builds without errors and that PVW
>>>>>>>>>>> launcher is functioning (new entries are added to the proxy file, vis
>>>>>>>>>>> sessions are created and are listening to ports in the specified range,
>>>>>>>>>>> etc.)
>>>>>>>>>>>
>>>>>>>>>>> We are trying to visualize a simple cone:
>>>>>>>>>>> (added app in launch.json)
>>>>>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py",
>>>>>>>>>>> "--port", "${port}"]}},
>>>>>>>>>>>
>>>>>>>>>>> We have verified that vtk_web_cone.py actually gets called. In
>>>>>>>>>>> order to test it, we used /pv/www/apps/TestApp/index.html as a template and
>>>>>>>>>>> created /pv/www/apps/Cone/index.html where we have:
>>>>>>>>>>> ...
>>>>>>>>>>> var config = {
>>>>>>>>>>> sessionManagerURL: vtkWeb.properties.sessionManagerURL,
>>>>>>>>>>> application: "cone"
>>>>>>>>>>> };
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> Now when we access this app via a browser at: http://<hostname>/apps/Cone/
>>>>>>>>>>> we either get a timeout or "connection can't be established" message.
>>>>>>>>>>>
>>>>>>>>>>> In the apache error log we see:
>>>>>>>>>>> [Sun Jul 20 16:04:15 2014] [error] [client 128.135.188.231]
>>>>>>>>>>> proxy: Error reading from remote server returned by /paraview/, referer:
>>>>>>>>>>> http://54.211.22.94/apps/Cone/
>>>>>>>>>>> [Sun Jul 20 16:04:15 2014] [error] [client 128.135.188.231] File
>>>>>>>>>>> does not exist: /pv/www/ws
>>>>>>>>>>>
>>>>>>>>>>> It appears that it has do to with Apache configuration, where we
>>>>>>>>>>> have:
>>>>>>>>>>> ProxyPass /paraview http://localhost:8080/paraview
>>>>>>>>>>> ProxyPassReverse /paraview http://localhost:8080/paraview
>>>>>>>>>>> RewriteEngine On
>>>>>>>>>>> RewriteMap session-to-port txt:/pv/conf/proxy.conf
>>>>>>>>>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
>>>>>>>>>>> RewriteRule ^/proxy.*$ ws://${session-to-port:%1}/ws [P]
>>>>>>>>>>>
>>>>>>>>>>> Do these Rewrite commands look right? How can their actions be
>>>>>>>>>>> logged and verified?
>>>>>>>>>>>
>>>>>>>>>>> Do we actually need ProxyPassReverse here?
>>>>>>>>>>>
>>>>>>>>>>> Is it possible that we are missing a module or some additional
>>>>>>>>>>> configuration in Apache?
>>>>>>>>>>> # apachectl -t -D DUMP_MODULES
>>>>>>>>>>> ...
>>>>>>>>>>> proxy_module (shared)
>>>>>>>>>>> proxy_http_module (shared)
>>>>>>>>>>> proxy_wstunnel_module (shared)
>>>>>>>>>>> rewrite_module (shared)
>>>>>>>>>>> ...
>>>>>>>>>>> Syntax OK
>>>>>>>>>>>
>>>>>>>>>>> Any debugging advice?
>>>>>>>>>>>
>>>>>>>>>>> Your help will be much appreciated and will allow to move
>>>>>>>>>>> forward with our isntallation.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> Dmitry Duplyakin
>>>>>>>>>>> PhD student, CS at University of Colorado - Boulder
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>
>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>
>>>>>>>>>>> Please keep messages on-topic and check the ParaView Wiki at:
>>>>>>>>>>> http://paraview.org/Wiki/ParaView
>>>>>>>>>>>
>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140721/861df0cf/attachment-0001.html>
More information about the ParaView
mailing list