[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Mon Jul 21 17:02:19 EDT 2014
Trying to follow instructions from
http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/paraviewweb_on_aws_ec2
now.
It looks like those urls used with wget are broken.
Found a replacement for httpd:
wget http://archive.apache.org/dist/httpd/httpd-2.4.7.tar.gz -O httpd.tgz
Can't seem to find 1.5.0 version. *Will 1.5.1 work?* If so, here is a
working command:
wget http://apache.petsads.us/apr/apr-1.5.1.tar.gz -O apr.tgz
The last one works fine:
wget http://apache.petsads.us/apr/apr-util-1.5.3.tar.gz -O apr-util.tgz
On Mon, Jul 21, 2014 at 3:36 PM, Dmitry Duplyakin <duplyakin at uchicago.edu>
wrote:
> 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/5ab03088/attachment-0001.html>
More information about the ParaView
mailing list