[Paraview] Visualizing a Cone with PVW - Connection can't be established
Sebastien Jourdain
sebastien.jourdain at kitware.com
Mon Jul 21 16:29:33 EDT 2014
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/20140721/ad65747a/attachment-0001.html>
More information about the ParaView
mailing list