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