[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Tue Jul 22 12:16:54 EDT 2014
Definitely worth checking.
Here is what I did to install it:
I used the script from: http://www.paraview.org/files/web/pvw-setup
which unpacks ParaView-4.1.0-Linux-64bit-glibc-2.3.6.tar.gz
and sets up directories like www, conf, etc.
Then in order to build ParaView from source I did: git://
paraview.org/stage/ParaView.git
followed by "git submodule update --init", as recommended at
http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/apache_setup
for Apache <2.4, which I was running until yesterday.
See anything wrong?
On Tue, Jul 22, 2014 at 10:47 AM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
> Just a though...
>
> Which version of ParaView did you build? git master?
>
> If so, did you use the www directory from that build or did you use the
> one from the binaries?
> There could be a version miss match in that later case.
>
> Seb
>
>
> On Tue, Jul 22, 2014 at 9:44 AM, Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> Hi Dmitry,
>>
>> I've just tried to connect to your server and it seems that the process
>> start in about 1s. That might be correct but it seems fast to me.
>> Do you see any error after the +++++ log file?
>>
>> Could you edit your launcher config to add an entry for the "pipeline"
>> app?
>> The cone is just relying on VTK and I was curious if we could see
>> something different with our main sample app that use paraview.
>>
>> For that you just need to kill the launcher process and restart it with
>> the new config.
>>
>> Seb
>>
>>
>> On Tue, Jul 22, 2014 at 8:39 AM, Dmitry Duplyakin <duplyakin at uchicago.edu
>> > wrote:
>>
>>> 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/f3c5abc8/attachment-0001.html>
More information about the ParaView
mailing list