[Paraview] Visualizing a Cone with PVW - Connection can't be established
Sebastien Jourdain
sebastien.jourdain at kitware.com
Tue Jul 22 15:36:10 EDT 2014
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/4b50e6c0/attachment-0001.html>
More information about the ParaView
mailing list