[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Tue Jul 22 16:07:36 EDT 2014
This makes sense and it most definitely helped!
We can now see this when we access: http://54.211.22.94/apps/Cone/
[image: Inline image 1]
but we are getting:
*uncaught exception: cannot resolve CURIE prefix 'vtk'*
What might be causing this?
On Tue, Jul 22, 2014 at 2:36 PM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
> The script is great when you don't want to build ParaView, but since you
> did, you should make sure the server and the client code (html+js) are in
> synch. Which is basically the content of that lib/ext/apps directories.
>
>
> On Tue, Jul 22, 2014 at 1:35 PM, Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> Yes you should replace the content of the directory that you share with
>> apache with the content that come from your {build-tree}/www.
>>
>> Just replace the three following dirs: apps, lib, ext
>>
>> Seb
>>
>>
>> On Tue, Jul 22, 2014 at 1:21 PM, Dmitry Duplyakin <duplyakin at uchicago.edu
>> > wrote:
>>
>>> Any comments on our build process?
>>>
>>> We are a bit concerned about compatibility between the stuff from that
>>> tar file and the stuff that we build from the cloned paraview code.
>>> Anything we should pay special attention to?
>>>
>>> Also, yesterday we saw the error when we called pvpython:
>>>
>>> /pv/paraview/lib/paraview-4.1/pvpython: error while loading shared
>>> libraries: libvtkPVServerManagerApplication-pv4.1.so.1: cannot open shared
>>> object file: No such file or directory
>>>
>>> and fixed it by adding
>>>
>>> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/pv/paraview/lib/paraview-4.1
>>>
>>> to our environment's profile. Seems to be a solved problem now, but can
>>> it possibly be caused by a compatibility issue?
>>>
>>> Finally, the cone file,
>>> /pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py, in our case
>>> remains in the src dir, the one where we clone paraview code from git. We
>>> understand that it is used with pvpython that knows about specific
>>> locations in our environment, but still it looks odd that the cone file
>>> remains in src, directory that can be considered for removal after
>>> installation is done. Are we missing something here?
>>>
>>>
>>> On Tue, Jul 22, 2014 at 11:16 AM, Dmitry Duplyakin <
>>> duplyakin at uchicago.edu> wrote:
>>>
>>>> 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/e6038a6a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 154565 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140722/e6038a6a/attachment-0001.png>
More information about the ParaView
mailing list