[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Tue Jul 22 10:39:56 EDT 2014
All I see is described js error. (I see it in the Firefox'es Firebug
console)
On Tue, Jul 22, 2014 at 9:33 AM, Dmitry Karpeyev <karpeev at mcs.anl.gov>
wrote:
> Is there a Python error/stack trace that comes with this?
> On Jul 22, 2014 9:30 AM, "Dmitry Duplyakin" <duplyakin at uchicago.edu>
> wrote:
>
>> Hi Sebastien,
>>
>> Thanks again for your help yesterday!
>>
>> We have upgraded and running Apache-2.4.7 now.
>>
>> We are seeing a now error:
>> Firefox can't establish a connection to the server at ws://
>> ec2-54-211-22-94.compute-1.amazonaws.com/proxy?sessionId=d9e328ce-11a9-11e4-b402-22000b0185a8
>> .
>> return new WebSocket(url, protocols);
>>
>> Last line points to code in autobahn.js
>> ab._construct = function (url, protocols) {
>> if ("WebSocket" in window) {
>> // Chrome, MSIE, newer Firefox
>> if (protocols) {
>> *return new WebSocket(url, protocols);*
>> } else {
>> return new WebSocket(url);
>> }
>> } else if ("MozWebSocket" in window) {
>> // older versions of Firefox prefix the WebSocket object
>> if (protocols) {
>> return new MozWebSocket(url, protocols);
>> } else {
>> return new MozWebSocket(url);
>> }
>> } else {
>> return null;
>> }
>> };
>>
>> In the meantime, session gets created, session log has a standard opening
>> followed by many lines with "+" signs (which means it is running fine,
>> right?), POST is successful:
>> 130.202.2.217 - - [22/Jul/2014:14:09:48 +0000] "POST /paraview/ HTTP/1.1"
>> 200 78 "http://54.211.22.94/apps/FileViewer/" "Mozilla/5.0 (Macintosh;
>> Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0".
>>
>> Its response:
>>
>> {"updir": "/Home", "sessionManagerURL": "http://54.211.22.94:/paraview/", "port": 9997, "host": "localhost", "sessionURL": "ws://ec2-54-211-22-94.compute-1.amazonaws.com/proxy?sessionId=d9e328ce-11a9-11e4-b402-22000b0185a8", "id": "d9e328ce-11a9-11e4-b402-22000b0185a8"}
>>
>> Are possibly missing anything here?
>>
>> Looks like Apache log verifies that wstunnel is working:
>>
>> [Tue Jul 22 14:26:22.617495 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2206): [client 130.202.2.217:63449] AH00947: connected /ws?sessionId=270f885c-11ac-11e4-b402-22000b0185a8 to localhost:9999
>> [Tue Jul 22 14:26:22.617574 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2610): AH00962: WS: connection complete to 127.0.0.1:9999 (localhost)
>> [Tue Jul 22 14:26:22.619784 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>> [Tue Jul 22 14:26:22.619806 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>> [Tue Jul 22 14:26:22.619905 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>> [Tue Jul 22 14:26:22.619925 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>> [Tue Jul 22 14:26:22.619943 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>> [Tue Jul 22 14:26:22.619953 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>> [Tue Jul 22 14:26:22.619964 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2035): AH00943: WS: has released connection for (*)
>>
>> Any thoughts on what might be causing this problem?
>>
>>
>> On Mon, Jul 21, 2014 at 4:06 PM, Sebastien Jourdain <
>> sebastien.jourdain at kitware.com> wrote:
>>
>>> Should work... I guess this documentation will always be out of date. ;-)
>>>
>>> But the good news is that modern system have the right version of
>>> Apache, so no fancy build are needed anymore...
>>>
>>> Seb
>>>
>>>
>>> On Mon, Jul 21, 2014 at 3:02 PM, Dmitry Duplyakin <
>>> duplyakin at uchicago.edu> wrote:
>>>
>>>> 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/20140722/ae5973e1/attachment-0001.html>
More information about the ParaView
mailing list