[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Tue Jul 22 10:30:33 EDT 2014
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/faa4d7cf/attachment-0001.html>
More information about the ParaView
mailing list