[Paraview] Visualizing a Cone with PVW - Connection can't be established
Dmitry Duplyakin
duplyakin at uchicago.edu
Tue Jul 22 18:14:59 EDT 2014
Yes, We have just resolved our last issue!!
[image: Inline image 1]
Sebastien, thank you so much for your generous help and patience!!
We are now making sure that we have configs, versions, paths, etc.
preserved and documented.
We are getting excited about using ParaViewWeb now and doing a number of
cool things with it!
On Tue, Jul 22, 2014 at 5:06 PM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
> It seems to work now... ;-)
>
>
> On Tue, Jul 22, 2014 at 2:07 PM, Dmitry Duplyakin <duplyakin at uchicago.edu>
> wrote:
>
>> This makes sense and it most definitely helped!
>>
>> We can now see this when we access: http://54.211.22.94/apps/Cone/
>>
>>
>> [image: Inline image 1]
>>
>> but we are getting:
>> *uncaught exception: cannot resolve CURIE prefix 'vtk'*
>>
>> What might be causing this?
>>
>>
>> On Tue, Jul 22, 2014 at 2:36 PM, Sebastien Jourdain <
>> sebastien.jourdain at kitware.com> wrote:
>>
>>> The script is great when you don't want to build ParaView, but since you
>>> did, you should make sure the server and the client code (html+js) are in
>>> synch. Which is basically the content of that lib/ext/apps directories.
>>>
>>>
>>> On Tue, Jul 22, 2014 at 1:35 PM, Sebastien Jourdain <
>>> sebastien.jourdain at kitware.com> wrote:
>>>
>>>> Yes you should replace the content of the directory that you share with
>>>> apache with the content that come from your {build-tree}/www.
>>>>
>>>> Just replace the three following dirs: apps, lib, ext
>>>>
>>>> Seb
>>>>
>>>>
>>>> On Tue, Jul 22, 2014 at 1:21 PM, Dmitry Duplyakin <
>>>> duplyakin at uchicago.edu> wrote:
>>>>
>>>>> Any comments on our build process?
>>>>>
>>>>> We are a bit concerned about compatibility between the stuff from that
>>>>> tar file and the stuff that we build from the cloned paraview code.
>>>>> Anything we should pay special attention to?
>>>>>
>>>>> Also, yesterday we saw the error when we called pvpython:
>>>>>
>>>>> /pv/paraview/lib/paraview-4.1/pvpython: error while loading shared
>>>>> libraries: libvtkPVServerManagerApplication-pv4.1.so.1: cannot open shared
>>>>> object file: No such file or directory
>>>>>
>>>>> and fixed it by adding
>>>>>
>>>>> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/pv/paraview/lib/paraview-4.1
>>>>>
>>>>> to our environment's profile. Seems to be a solved problem now, but
>>>>> can it possibly be caused by a compatibility issue?
>>>>>
>>>>> Finally, the cone file,
>>>>> /pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py, in our case
>>>>> remains in the src dir, the one where we clone paraview code from git. We
>>>>> understand that it is used with pvpython that knows about specific
>>>>> locations in our environment, but still it looks odd that the cone file
>>>>> remains in src, directory that can be considered for removal after
>>>>> installation is done. Are we missing something here?
>>>>>
>>>>>
>>>>> On Tue, Jul 22, 2014 at 11:16 AM, Dmitry Duplyakin <
>>>>> duplyakin at uchicago.edu> wrote:
>>>>>
>>>>>> Definitely worth checking.
>>>>>>
>>>>>> Here is what I did to install it:
>>>>>>
>>>>>> I used the script from: http://www.paraview.org/files/web/pvw-setup
>>>>>>
>>>>>> which unpacks ParaView-4.1.0-Linux-64bit-glibc-2.3.6.tar.gz
>>>>>>
>>>>>> and sets up directories like www, conf, etc.
>>>>>>
>>>>>> Then in order to build ParaView from source I did: git://
>>>>>> paraview.org/stage/ParaView.git
>>>>>>
>>>>>> followed by "git submodule update --init", as recommended at
>>>>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/apache_setup
>>>>>>
>>>>>> for Apache <2.4, which I was running until yesterday.
>>>>>>
>>>>>> See anything wrong?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 22, 2014 at 10:47 AM, Sebastien Jourdain <
>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>
>>>>>>> Just a though...
>>>>>>>
>>>>>>> Which version of ParaView did you build? git master?
>>>>>>>
>>>>>>> If so, did you use the www directory from that build or did you use
>>>>>>> the one from the binaries?
>>>>>>> There could be a version miss match in that later case.
>>>>>>>
>>>>>>> Seb
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 22, 2014 at 9:44 AM, Sebastien Jourdain <
>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>
>>>>>>>> Hi Dmitry,
>>>>>>>>
>>>>>>>> I've just tried to connect to your server and it seems that the
>>>>>>>> process start in about 1s. That might be correct but it seems fast to me.
>>>>>>>> Do you see any error after the +++++ log file?
>>>>>>>>
>>>>>>>> Could you edit your launcher config to add an entry for the
>>>>>>>> "pipeline" app?
>>>>>>>> The cone is just relying on VTK and I was curious if we could see
>>>>>>>> something different with our main sample app that use paraview.
>>>>>>>>
>>>>>>>> For that you just need to kill the launcher process and restart it
>>>>>>>> with the new config.
>>>>>>>>
>>>>>>>> Seb
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 22, 2014 at 8:39 AM, Dmitry Duplyakin <
>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>
>>>>>>>>> All I see is described js error. (I see it in the Firefox'es
>>>>>>>>> Firebug console)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 22, 2014 at 9:33 AM, Dmitry Karpeyev <
>>>>>>>>> karpeev at mcs.anl.gov> wrote:
>>>>>>>>>
>>>>>>>>>> Is there a Python error/stack trace that comes with this?
>>>>>>>>>> On Jul 22, 2014 9:30 AM, "Dmitry Duplyakin" <
>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Sebastien,
>>>>>>>>>>>
>>>>>>>>>>> Thanks again for your help yesterday!
>>>>>>>>>>>
>>>>>>>>>>> We have upgraded and running Apache-2.4.7 now.
>>>>>>>>>>>
>>>>>>>>>>> We are seeing a now error:
>>>>>>>>>>> Firefox can't establish a connection to the server at ws://
>>>>>>>>>>> ec2-54-211-22-94.compute-1.amazonaws.com/proxy?sessionId=d9e328ce-11a9-11e4-b402-22000b0185a8
>>>>>>>>>>> .
>>>>>>>>>>> return new WebSocket(url, protocols);
>>>>>>>>>>>
>>>>>>>>>>> Last line points to code in autobahn.js
>>>>>>>>>>> ab._construct = function (url, protocols) {
>>>>>>>>>>> if ("WebSocket" in window) {
>>>>>>>>>>> // Chrome, MSIE, newer Firefox
>>>>>>>>>>> if (protocols) {
>>>>>>>>>>> *return new WebSocket(url, protocols);*
>>>>>>>>>>> } else {
>>>>>>>>>>> return new WebSocket(url);
>>>>>>>>>>> }
>>>>>>>>>>> } else if ("MozWebSocket" in window) {
>>>>>>>>>>> // older versions of Firefox prefix the WebSocket object
>>>>>>>>>>> if (protocols) {
>>>>>>>>>>> return new MozWebSocket(url, protocols);
>>>>>>>>>>> } else {
>>>>>>>>>>> return new MozWebSocket(url);
>>>>>>>>>>> }
>>>>>>>>>>> } else {
>>>>>>>>>>> return null;
>>>>>>>>>>> }
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> In the meantime, session gets created, session log has a
>>>>>>>>>>> standard opening followed by many lines with "+" signs (which means it is
>>>>>>>>>>> running fine, right?), POST is successful:
>>>>>>>>>>> 130.202.2.217 - - [22/Jul/2014:14:09:48 +0000] "POST /paraview/
>>>>>>>>>>> HTTP/1.1" 200 78 "http://54.211.22.94/apps/FileViewer/"
>>>>>>>>>>> "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101
>>>>>>>>>>> Firefox/30.0".
>>>>>>>>>>>
>>>>>>>>>>> Its response:
>>>>>>>>>>>
>>>>>>>>>>> {"updir": "/Home", "sessionManagerURL": "http://54.211.22.94:/paraview/", "port": 9997, "host": "localhost", "sessionURL": "ws://ec2-54-211-22-94.compute-1.amazonaws.com/proxy?sessionId=d9e328ce-11a9-11e4-b402-22000b0185a8", "id": "d9e328ce-11a9-11e4-b402-22000b0185a8"}
>>>>>>>>>>>
>>>>>>>>>>> Are possibly missing anything here?
>>>>>>>>>>>
>>>>>>>>>>> Looks like Apache log verifies that wstunnel is working:
>>>>>>>>>>>
>>>>>>>>>>> [Tue Jul 22 14:26:22.617495 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2206): [client 130.202.2.217:63449] AH00947: connected /ws?sessionId=270f885c-11ac-11e4-b402-22000b0185a8 to localhost:9999
>>>>>>>>>>> [Tue Jul 22 14:26:22.617574 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2610): AH00962: WS: connection complete to 127.0.0.1:9999 (localhost)
>>>>>>>>>>> [Tue Jul 22 14:26:22.619784 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>>>>>>>>>>> [Tue Jul 22 14:26:22.619806 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>>>>>>>>>>> [Tue Jul 22 14:26:22.619905 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>>>>>>>>>>> [Tue Jul 22 14:26:22.619925 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>>>>>>>>>>> [Tue Jul 22 14:26:22.619943 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(253): [client 130.202.2.217:63449] AH02445: woke from poll(), i=1
>>>>>>>>>>> [Tue Jul 22 14:26:22.619953 2014] [proxy_wstunnel:debug] [pid 7236:tid 140393354098432] mod_proxy_wstunnel.c(262): [client 130.202.2.217:63449] AH02446: sock was readable
>>>>>>>>>>> [Tue Jul 22 14:26:22.619964 2014] [proxy:debug] [pid 7236:tid 140393354098432] proxy_util.c(2035): AH00943: WS: has released connection for (*)
>>>>>>>>>>>
>>>>>>>>>>> Any thoughts on what might be causing this problem?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 21, 2014 at 4:06 PM, Sebastien Jourdain <
>>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Should work... I guess this documentation will always be out of
>>>>>>>>>>>> date. ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> But the good news is that modern system have the right version
>>>>>>>>>>>> of Apache, so no fancy build are needed anymore...
>>>>>>>>>>>>
>>>>>>>>>>>> Seb
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 21, 2014 at 3:02 PM, Dmitry Duplyakin <
>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Trying to follow instructions from
>>>>>>>>>>>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/paraviewweb_on_aws_ec2 now.
>>>>>>>>>>>>> It looks like those urls used with wget are broken.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found a replacement for httpd:
>>>>>>>>>>>>>
>>>>>>>>>>>>> wget http://archive.apache.org/dist/httpd/httpd-2.4.7.tar.gz
>>>>>>>>>>>>> -O httpd.tgz
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can't seem to find 1.5.0 version. *Will 1.5.1 work?* If so,
>>>>>>>>>>>>> here is a working command:
>>>>>>>>>>>>>
>>>>>>>>>>>>> wget http://apache.petsads.us/apr/apr-1.5.1.tar.gz -O apr.tgz
>>>>>>>>>>>>>
>>>>>>>>>>>>> The last one works fine:
>>>>>>>>>>>>>
>>>>>>>>>>>>> wget http://apache.petsads.us/apr/apr-util-1.5.3.tar.gz -O
>>>>>>>>>>>>> apr-util.tgz
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 3:36 PM, Dmitry Duplyakin <
>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Got it. Rebuilding Apache now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 3:29 PM, Sebastien Jourdain <
>>>>>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You must have Apache 2.4.7+
>>>>>>>>>>>>>>> Their is a fix in that version which allow mod_rewrite to
>>>>>>>>>>>>>>> work on web socket protocol instead of just http.
>>>>>>>>>>>>>>> You can look at the apache section in here
>>>>>>>>>>>>>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/paraviewweb_on_aws_ec2
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 2:25 PM, Dmitry Duplyakin <
>>>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We are running Apache/2.2.22 with loaded
>>>>>>>>>>>>>>>> proxy_wstunnel_module (that we had to build from source).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> From Apache error log (with debug):
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy_http.c(56):
>>>>>>>>>>>>>>>> proxy: HTTP: canonicalising URL //localhost:8080/paraview/
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(1506):
>>>>>>>>>>>>>>>> [client 130.202.2.217] proxy: http: found worker
>>>>>>>>>>>>>>>> http://localhost:8080/paraview for
>>>>>>>>>>>>>>>> http://localhost:8080/paraview/, referer:
>>>>>>>>>>>>>>>> http://54.211.22.94/apps/Cone/
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy.c(1020):
>>>>>>>>>>>>>>>> Running scheme http handler (attempt 0)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] mod_proxy_http.c(1973):
>>>>>>>>>>>>>>>> proxy: HTTP: serving URL http://localhost:8080/paraview/
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2011):
>>>>>>>>>>>>>>>> proxy: HTTP: has acquired connection for (localhost)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2067):
>>>>>>>>>>>>>>>> proxy: connecting http://localhost:8080/paraview/ to
>>>>>>>>>>>>>>>> localhost:8080
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:13 2014] [debug] proxy_util.c(2193):
>>>>>>>>>>>>>>>> proxy: connected /paraview/ to localhost:8080
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1743):
>>>>>>>>>>>>>>>> proxy: start body send
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_deflate.c(615):
>>>>>>>>>>>>>>>> [client 130.202.2.217] Zlib: Compressed 242 to 155 : URL /paraview/,
>>>>>>>>>>>>>>>> referer: http://54.211.22.94/apps/Cone/
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1847):
>>>>>>>>>>>>>>>> proxy: end body send
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2029):
>>>>>>>>>>>>>>>> proxy: HTTP: has released connection for (localhost)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(56):
>>>>>>>>>>>>>>>> proxy: HTTP: canonicalising URL //
>>>>>>>>>>>>>>>> 54.211.22.94/ws://localhost:9998/ws
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(1525):
>>>>>>>>>>>>>>>> [client 130.202.2.217] proxy: *: found reverse proxy worker for
>>>>>>>>>>>>>>>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy.c(1020):
>>>>>>>>>>>>>>>> Running scheme http handler (attempt 0)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1973):
>>>>>>>>>>>>>>>> proxy: HTTP: serving URL
>>>>>>>>>>>>>>>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2011):
>>>>>>>>>>>>>>>> proxy: HTTP: has acquired connection for (*)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2067):
>>>>>>>>>>>>>>>> proxy: connecting
>>>>>>>>>>>>>>>> http://54.211.22.94/ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8
>>>>>>>>>>>>>>>> to 54.211.22.94:80
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2193):
>>>>>>>>>>>>>>>> proxy: connected
>>>>>>>>>>>>>>>> /ws://localhost:9998/ws?sessionId=6bf080cc-1114-11e4-b402-22000b0185a8 to
>>>>>>>>>>>>>>>> 54.211.22.94:80
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2444):
>>>>>>>>>>>>>>>> proxy: HTTP: fam 2 socket created to connect to *
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2576):
>>>>>>>>>>>>>>>> proxy: HTTP: connection complete to 54.211.22.94:80
>>>>>>>>>>>>>>>> (54.211.22.94)
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [error] [client 54.211.22.94]
>>>>>>>>>>>>>>>> File does not exist: /pv/www/ws:
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1743):
>>>>>>>>>>>>>>>> proxy: start body send
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] mod_proxy_http.c(1847):
>>>>>>>>>>>>>>>> proxy: end body send
>>>>>>>>>>>>>>>> [Mon Jul 21 20:20:14 2014] [debug] proxy_util.c(2029):
>>>>>>>>>>>>>>>> proxy: HTTP: has released connection for (*)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> POST took ~1 second. Timestamps for POST and the following
>>>>>>>>>>>>>>>> GET: 21/Jul/2014:20:23:02 and 21/Jul/2014:20:23:03
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 3:10 PM, Sebastien Jourdain <
>>>>>>>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which version of Apache are you using? Do you have the
>>>>>>>>>>>>>>>>> ws_tunnelling (<= wrong name but something like that) module enabled?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You may be able to check the system log that apache
>>>>>>>>>>>>>>>>> generate to see what went wrong.
>>>>>>>>>>>>>>>>> Do you know how much time the POST request took?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 1:59 PM, Dmitry Duplyakin <
>>>>>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Continue troubleshooting...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now we get this in response to POST:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> {"updir": "/Home", "sessionManagerURL":
>>>>>>>>>>>>>>>>>> "http://54.211.22.94:/paraview/", "port": 9999, "host":
>>>>>>>>>>>>>>>>>> "localhost", "sessionURL": "ws://
>>>>>>>>>>>>>>>>>> 54.211.22.94/proxy?sessionId=369f8648-110f-11e4-b402-22000b0185a8",
>>>>>>>>>>>>>>>>>> "id": "369f8648-110f-11e4-b402-22000b0185a8"}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looks right to me. Then, after that POST, it does GETs
>>>>>>>>>>>>>>>>>> that do not look right:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 54.211.22.94 - - [21/Jul/2014:19:54:29 +0000] "GET
>>>>>>>>>>>>>>>>>> */ws://localhost:9999/ws?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8*
>>>>>>>>>>>>>>>>>> HTTP/1.1" 404 509 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
>>>>>>>>>>>>>>>>>> rv:30.0) Gecko/20100101 Firefox/30.0"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 130.202.2.217 - - [21/Jul/2014:19:54:29 +0000] "GET
>>>>>>>>>>>>>>>>>> /proxy?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8 HTTP/1.1" 404 509 "-"
>>>>>>>>>>>>>>>>>> "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101
>>>>>>>>>>>>>>>>>> Firefox/30.0"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And the message:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Firefox can't establish a connection to the server at
>>>>>>>>>>>>>>>>>> ws://
>>>>>>>>>>>>>>>>>> 54.211.22.94/proxy?sessionId=d32a4d8a-1110-11e4-b402-22000b0185a8.
>>>>>>>>>>>>>>>>>> return new WebSocket(url, protocols);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What can possibly cause this? Again, complete apache and
>>>>>>>>>>>>>>>>>> launcher configs are in the previous email.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 2:07 PM, Dmitry Duplyakin <
>>>>>>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This helped tremendously!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Both "-f" and "${host}" now make a lot more sense.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> POST works fine now and we can see the Rewrite rule in
>>>>>>>>>>>>>>>>>>> action. Something there still needs attention and we are investigating
>>>>>>>>>>>>>>>>>>> further.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for you patience and all the help that allows us
>>>>>>>>>>>>>>>>>>> to move forward.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 12:59 PM, Sebastien Jourdain <
>>>>>>>>>>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> you may still have a typo
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> => "ws://${host}/proxy?sessionId=${id}",
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ${host} should have been replaced with a static string
>>>>>>>>>>>>>>>>>>>> that match the host that the web browser is using to reach apache.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Moreover, I forgot to mention that you need to add "-f"
>>>>>>>>>>>>>>>>>>>> in your set of arguments. That will force some output generation to fill
>>>>>>>>>>>>>>>>>>>> some buffer which will allow the launcher to detect when the server is
>>>>>>>>>>>>>>>>>>>> actually ready.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I've noticed that the documentation is missing them.
>>>>>>>>>>>>>>>>>>>> Don't know why... Will update it at some point.
>>>>>>>>>>>>>>>>>>>> Although this page show that option:
>>>>>>>>>>>>>>>>>>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/py_launcher
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And the value for "timeout" should be way bigger than
>>>>>>>>>>>>>>>>>>>> 5. Like 25 maybe.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 10:58 AM, Dmitry Duplyakin <
>>>>>>>>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks for this detailed description! The process is
>>>>>>>>>>>>>>>>>>>>> starting to make sense and we can communicate more efficiently about our
>>>>>>>>>>>>>>>>>>>>> configuration and problems.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Here is our complete launch.json (with the right
>>>>>>>>>>>>>>>>>>>>> sessionURL for a config with Apache, according to your email):
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> "configuration": {
>>>>>>>>>>>>>>>>>>>>> "content": "/pv/www",
>>>>>>>>>>>>>>>>>>>>> "log_dir": "/pv/logs",
>>>>>>>>>>>>>>>>>>>>> "host": "localhost",
>>>>>>>>>>>>>>>>>>>>> "endpoint": "paraview",
>>>>>>>>>>>>>>>>>>>>> "sessionURL": "ws://${host}/proxy?sessionId=${id}",
>>>>>>>>>>>>>>>>>>>>> "timeout": 5,
>>>>>>>>>>>>>>>>>>>>> "upload_dir": "/pv/data",
>>>>>>>>>>>>>>>>>>>>> "fields": ["file", "host", "port", "updir"],
>>>>>>>>>>>>>>>>>>>>> "port": 8080,
>>>>>>>>>>>>>>>>>>>>> "proxy_file": "/pv/conf/proxy.conf"},
>>>>>>>>>>>>>>>>>>>>> "apps": {
>>>>>>>>>>>>>>>>>>>>> "data_prober": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>> "${python_path}/paraview/web/pv_web_data_prober.py", "--port", "${port}",
>>>>>>>>>>>>>>>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>>>>>>>>>>>>>>>> "pipeline": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>> "${python_path}/paraview/web/pv_web_visualizer.py", "--port", "${port}",
>>>>>>>>>>>>>>>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>>>>>>>>>>>>>>>> "loader": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>> "${python_path}/paraview/web/pv_web_file_loader.py", "--port", "${port}",
>>>>>>>>>>>>>>>>>>>>> "--data-dir", "${data}"], "ready_line" : "Starting factory"},
>>>>>>>>>>>>>>>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py", "--port",
>>>>>>>>>>>>>>>>>>>>> "${port}"], "ready_line" : "Starting factory"}},
>>>>>>>>>>>>>>>>>>>>> "properties": {
>>>>>>>>>>>>>>>>>>>>> "python_path":
>>>>>>>>>>>>>>>>>>>>> "/pv/paraview/lib/paraview-4.1/site-packages/",
>>>>>>>>>>>>>>>>>>>>> "data": "/pv/data",
>>>>>>>>>>>>>>>>>>>>> "python_exec": "/pv/paraview/bin/pvpython"},
>>>>>>>>>>>>>>>>>>>>> "resources": [{"port_range": [9901, 9999], "host":
>>>>>>>>>>>>>>>>>>>>> "localhost"}],
>>>>>>>>>>>>>>>>>>>>> "sessionData": {"updir": "/Home"}
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Apache host file:
>>>>>>>>>>>>>>>>>>>>> <VirtualHost *:80>
>>>>>>>>>>>>>>>>>>>>> ServerAdmin webmaster at localhost
>>>>>>>>>>>>>>>>>>>>> DocumentRoot /pv/www
>>>>>>>>>>>>>>>>>>>>> <Directory /pv/www/>
>>>>>>>>>>>>>>>>>>>>> Options Indexes FollowSymLinks
>>>>>>>>>>>>>>>>>>>>> MultiViews
>>>>>>>>>>>>>>>>>>>>> AllowOverride None
>>>>>>>>>>>>>>>>>>>>> Order allow,deny
>>>>>>>>>>>>>>>>>>>>> allow from all
>>>>>>>>>>>>>>>>>>>>> </Directory>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ProxyPass /paraview
>>>>>>>>>>>>>>>>>>>>> http://localhost:8080/paraview
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> RewriteEngine On
>>>>>>>>>>>>>>>>>>>>> RewriteMap session-to-port
>>>>>>>>>>>>>>>>>>>>> txt:/pv/conf/proxy.conf
>>>>>>>>>>>>>>>>>>>>> RewriteCond %{QUERY_STRING}
>>>>>>>>>>>>>>>>>>>>> ^sessionId=(.*)$ [NC]
>>>>>>>>>>>>>>>>>>>>> RewriteRule ^/proxy.*$
>>>>>>>>>>>>>>>>>>>>> ws://${session-to-port:%1}/ws [P]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> RewriteLog "/var/log/apache2/rewrite.log"
>>>>>>>>>>>>>>>>>>>>> RewriteLogLevel 3
>>>>>>>>>>>>>>>>>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>>>>>>>>>>>>>>>>>>>>> LogLevel debug
>>>>>>>>>>>>>>>>>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>>>>>>>>>>>>>>>>>>>>> </VirtualHost>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Now when we access http://<PVW server>/apps/Cone/ in
>>>>>>>>>>>>>>>>>>>>> the browser,
>>>>>>>>>>>>>>>>>>>>> it does POST {"sessionManagerURL":"http://<CORRECT IP
>>>>>>>>>>>>>>>>>>>>> FOR PVW server>:/paraview/","application":"cone"}. Then Launcher starts a
>>>>>>>>>>>>>>>>>>>>> process listening to a port from the range (e.g. 9999). We can see that
>>>>>>>>>>>>>>>>>>>>> process:
>>>>>>>>>>>>>>>>>>>>> ps auwx | grep cone
>>>>>>>>>>>>>>>>>>>>> root 27943 2.3 1.8 1015600 137664 pts/2 Sl+
>>>>>>>>>>>>>>>>>>>>> 16:32 0:00 /pv/paraview/lib/paraview-4.1/pvpython
>>>>>>>>>>>>>>>>>>>>> /pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py --port 9999
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> After that we get a session timeout and this response: "Session
>>>>>>>>>>>>>>>>>>>>> did not start before timeout expired. Check session logs."
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any further advice?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 10:02 AM, Sebastien Jourdain <
>>>>>>>>>>>>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> First of all you need to understand the role of
>>>>>>>>>>>>>>>>>>>>>> apache here in order to see how the configuration should be.
>>>>>>>>>>>>>>>>>>>>>> As you may know, you can use ParaViewWeb without
>>>>>>>>>>>>>>>>>>>>>> Apache, but such setup is not meant for production.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The list below is what you get when you add Apache:
>>>>>>>>>>>>>>>>>>>>>> - Apache can be use to serve the static content
>>>>>>>>>>>>>>>>>>>>>> (html, js, png, css...)
>>>>>>>>>>>>>>>>>>>>>> - Apache provide a single entry point host + port.
>>>>>>>>>>>>>>>>>>>>>> This prevent cross-domain issue or firewall limitation.
>>>>>>>>>>>>>>>>>>>>>> - Apache will relay the WebSocket communication to
>>>>>>>>>>>>>>>>>>>>>> the proper ParaViewWeb instance on the backend based on a session ID. This
>>>>>>>>>>>>>>>>>>>>>> mean that the ParaViewWeb process DOES NOT need to be on the same machine
>>>>>>>>>>>>>>>>>>>>>> as the Apache Web Server.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then you need to understand how the launcher works
>>>>>>>>>>>>>>>>>>>>>> and its role.
>>>>>>>>>>>>>>>>>>>>>> In ParaViewWeb a launcher is used to start a new
>>>>>>>>>>>>>>>>>>>>>> visualization process for a given user. This simply mean running a command
>>>>>>>>>>>>>>>>>>>>>> line with some dynamic parameters like the port number on which this
>>>>>>>>>>>>>>>>>>>>>> specific instance should listen.
>>>>>>>>>>>>>>>>>>>>>> So when a user connect to the system and request a
>>>>>>>>>>>>>>>>>>>>>> new visualization session, it is the responsibility of the launcher to
>>>>>>>>>>>>>>>>>>>>>> start the process and let the client know on which WebSocket URL it should
>>>>>>>>>>>>>>>>>>>>>> connect to in order to reach the requested visualization session.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In a setup that DOES NOT contain Apache, we can not
>>>>>>>>>>>>>>>>>>>>>> use the same port as the main server (the process would not start). Hence,
>>>>>>>>>>>>>>>>>>>>>> we start it with some port and we let the user know that it should connect
>>>>>>>>>>>>>>>>>>>>>> to "ws://{host}:{port}/ws" where host and port get replaced with the set
>>>>>>>>>>>>>>>>>>>>>> that was used to create the process.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> See section "resources" in launcher configuration.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> BUT with Apache that is different, now we have a
>>>>>>>>>>>>>>>>>>>>>> process which is meant to relay the communication to the backend using the
>>>>>>>>>>>>>>>>>>>>>> port and host that Apache is using. So the launcher should let the client
>>>>>>>>>>>>>>>>>>>>>> know what URL they should use so Apache could handle it and forward it to
>>>>>>>>>>>>>>>>>>>>>> the backend. Hence the ws://{apache_host}/proxy?sessionId=${id}.
>>>>>>>>>>>>>>>>>>>>>> In the same time to keep track on which host/port a
>>>>>>>>>>>>>>>>>>>>>> process is running the launcher generate a text file with the proper
>>>>>>>>>>>>>>>>>>>>>> mapping.
>>>>>>>>>>>>>>>>>>>>>> That mapping file is then used inside Apache to
>>>>>>>>>>>>>>>>>>>>>> figure out how it should establish the connection to the backend.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This should help you understand how to fix your
>>>>>>>>>>>>>>>>>>>>>> configuration.
>>>>>>>>>>>>>>>>>>>>>> Moreover, here is the remaining set of questions:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> > can we specifically log and debug Rewrite rule
>>>>>>>>>>>>>>>>>>>>>> actions?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Don't know, Google will be your friend here...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> > do we actually need ProxyPassReverse in Apache?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Don't know, Google will be your friend here as well
>>>>>>>>>>>>>>>>>>>>>> as the documentation on how to setup ParaViewWeb on Ubuntu 14LTS.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> > what particular modules in Apache are required?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Read the documentation, the list is minimum and
>>>>>>>>>>>>>>>>>>>>>> provided in it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> > in launch.json there are two particular lines
>>>>>>>>>>>>>>>>>>>>>> host/resources:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So the "host" is to select the proper network card
>>>>>>>>>>>>>>>>>>>>>> when you have several for the actual launcher server.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then the resources are use for process management and
>>>>>>>>>>>>>>>>>>>>>> URL generation for the client. Which mean, what name should be used by
>>>>>>>>>>>>>>>>>>>>>> Apache to connect to the machine that actually run a ParaViewWeb process.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 21, 2014 at 8:01 AM, Dmitry Duplyakin <
>>>>>>>>>>>>>>>>>>>>>> duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thank you very much, Sebastien!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Launcher side:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> "sessionURL": "ws://YOUR_HOST_NAME_TO_REPLACE(the one used to connect to apache)/proxy?sessionId=${id}",
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> "proxy_file": "/data/proxy.txt"
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is exactly what we have in our launcher:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "sessionURL": "ws://${host}:${port}/ws",
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "host": "localhost",
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "port": 8080,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Your sessionURL looks different. Do you actually use
>>>>>>>>>>>>>>>>>>>>>>> "proxy?sessionId=" there? Ours came directly from
>>>>>>>>>>>>>>>>>>>>>>> the script you've suggested earlier:
>>>>>>>>>>>>>>>>>>>>>>> http://www.paraview.org/gitweb?p=ParaViewSuperbuild.git;a=blob_plain;f=Scripts/pvw-setup.py;hb=HEAD
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Apache side
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> RewriteMap session-to-port txt:/data/proxy.txt
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In Apache we have:
>>>>>>>>>>>>>>>>>>>>>>> RewriteEngine On
>>>>>>>>>>>>>>>>>>>>>>> RewriteMap session-to-port txt:/pv/conf/proxy.conf
>>>>>>>>>>>>>>>>>>>>>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
>>>>>>>>>>>>>>>>>>>>>>> RewriteRule ^/proxy.*$
>>>>>>>>>>>>>>>>>>>>>>> ws://${session-to-port:%1}/ws [P]
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Then when a session start you can check the content
>>>>>>>>>>>>>>>>>>>>>>>> of that /data/proxy.txt and that should one line by running session with
>>>>>>>>>>>>>>>>>>>>>>>> {sessionId} localhost:yyyyy
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Verified that those entires are added to the file
>>>>>>>>>>>>>>>>>>>>>>> and have the right format.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On the other hand you forgot that line in the
>>>>>>>>>>>>>>>>>>>>>>>> config of your cone app: "ready_line" : "Starting
>>>>>>>>>>>>>>>>>>>>>>>> factory"
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks! Added it and now the app looks like this:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py",
>>>>>>>>>>>>>>>>>>>>>>> "--port", "${port}"], "ready_line" : "Starting
>>>>>>>>>>>>>>>>>>>>>>> factory"}},
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You can check is any pvpython process is running,
>>>>>>>>>>>>>>>>>>>>>>>> on which port, see if that match in the proxy file (/data/proxy.txt) and
>>>>>>>>>>>>>>>>>>>>>>>> also looking at the log directory with the output of the pvpython process.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> A common error could also be that the apache does
>>>>>>>>>>>>>>>>>>>>>>>> not have the right to read the /data/proxy.txt file or that the launcher is
>>>>>>>>>>>>>>>>>>>>>>>> not able to write it.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Verified that launcher can write it and that entries
>>>>>>>>>>>>>>>>>>>>>>> are added.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> These are the rest of our questions (we need to sort
>>>>>>>>>>>>>>>>>>>>>>> these out because they have caused some confusion and we want to clear
>>>>>>>>>>>>>>>>>>>>>>> things up and do not come back to these issues anymore):
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> - can we specifically log and debug Rewrite rule
>>>>>>>>>>>>>>>>>>>>>>> actions?
>>>>>>>>>>>>>>>>>>>>>>> - do we actually need ProxyPassReverse in Apache?
>>>>>>>>>>>>>>>>>>>>>>> - what particular modules in Apache are required? So
>>>>>>>>>>>>>>>>>>>>>>> far we have: proxy_module, proxy_http_module, and rewrite_module. We are
>>>>>>>>>>>>>>>>>>>>>>> unsure whether we need proxy_wstunnel_module or not.
>>>>>>>>>>>>>>>>>>>>>>> - in launch.json there are two particular lines:
>>>>>>>>>>>>>>>>>>>>>>> "host": "localhost",
>>>>>>>>>>>>>>>>>>>>>>> "resources": [{"port_range": [9901, 9999], "host":
>>>>>>>>>>>>>>>>>>>>>>> "localhost"}],
>>>>>>>>>>>>>>>>>>>>>>> where we have some confusion about using "localhost"
>>>>>>>>>>>>>>>>>>>>>>> vs. "0.0.0.0". What exactly should we use in either case?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Appreciate your help!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Good luck,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Jul 20, 2014 at 10:12 AM, Dmitry Duplyakin
>>>>>>>>>>>>>>>>>>>>>>>> <duplyakin at uchicago.edu> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> My name is Dmitry Duplyakin. I am a PhD student
>>>>>>>>>>>>>>>>>>>>>>>>> helping to build a ParaViewWeb system at University of Chicago.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We are building ParaView 4.1.0 (with OSMesa) on
>>>>>>>>>>>>>>>>>>>>>>>>> Amazon EC2 Ubuntu 12.04 instances.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We have verified that PV builds without errors and
>>>>>>>>>>>>>>>>>>>>>>>>> that PVW launcher is functioning (new entries are added to the proxy file,
>>>>>>>>>>>>>>>>>>>>>>>>> vis sessions are created and are listening to ports in the specified range,
>>>>>>>>>>>>>>>>>>>>>>>>> etc.)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We are trying to visualize a simple cone:
>>>>>>>>>>>>>>>>>>>>>>>>> (added app in launch.json)
>>>>>>>>>>>>>>>>>>>>>>>>> "cone": {"cmd": ["${python_exec}",
>>>>>>>>>>>>>>>>>>>>>>>>> "/pv/src/VTK/Web/Applications/Cone/server/vtk_web_cone.py",
>>>>>>>>>>>>>>>>>>>>>>>>> "--port", "${port}"]}},
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We have verified that vtk_web_cone.py actually
>>>>>>>>>>>>>>>>>>>>>>>>> gets called. In order to test it, we used /pv/www/apps/TestApp/index.html
>>>>>>>>>>>>>>>>>>>>>>>>> as a template and created /pv/www/apps/Cone/index.html where we have:
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>> var config = {
>>>>>>>>>>>>>>>>>>>>>>>>> sessionManagerURL:
>>>>>>>>>>>>>>>>>>>>>>>>> vtkWeb.properties.sessionManagerURL,
>>>>>>>>>>>>>>>>>>>>>>>>> application: "cone"
>>>>>>>>>>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Now when we access this app via a browser at:
>>>>>>>>>>>>>>>>>>>>>>>>> http://<hostname>/apps/Cone/ we either get a
>>>>>>>>>>>>>>>>>>>>>>>>> timeout or "connection can't be established" message.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> In the apache error log we see:
>>>>>>>>>>>>>>>>>>>>>>>>> [Sun Jul 20 16:04:15 2014] [error] [client
>>>>>>>>>>>>>>>>>>>>>>>>> 128.135.188.231] proxy: Error reading from remote server returned by
>>>>>>>>>>>>>>>>>>>>>>>>> /paraview/, referer:
>>>>>>>>>>>>>>>>>>>>>>>>> http://54.211.22.94/apps/Cone/
>>>>>>>>>>>>>>>>>>>>>>>>> [Sun Jul 20 16:04:15 2014] [error] [client
>>>>>>>>>>>>>>>>>>>>>>>>> 128.135.188.231] File does not exist: /pv/www/ws
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It appears that it has do to with Apache
>>>>>>>>>>>>>>>>>>>>>>>>> configuration, where we have:
>>>>>>>>>>>>>>>>>>>>>>>>> ProxyPass /paraview
>>>>>>>>>>>>>>>>>>>>>>>>> http://localhost:8080/paraview
>>>>>>>>>>>>>>>>>>>>>>>>> ProxyPassReverse /paraview
>>>>>>>>>>>>>>>>>>>>>>>>> http://localhost:8080/paraview
>>>>>>>>>>>>>>>>>>>>>>>>> RewriteEngine On
>>>>>>>>>>>>>>>>>>>>>>>>> RewriteMap session-to-port txt:/pv/conf/proxy.conf
>>>>>>>>>>>>>>>>>>>>>>>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$
>>>>>>>>>>>>>>>>>>>>>>>>> [NC]
>>>>>>>>>>>>>>>>>>>>>>>>> RewriteRule ^/proxy.*$
>>>>>>>>>>>>>>>>>>>>>>>>> ws://${session-to-port:%1}/ws [P]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Do these Rewrite commands look right? How can
>>>>>>>>>>>>>>>>>>>>>>>>> their actions be logged and verified?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Do we actually need ProxyPassReverse here?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Is it possible that we are missing a module or
>>>>>>>>>>>>>>>>>>>>>>>>> some additional configuration in Apache?
>>>>>>>>>>>>>>>>>>>>>>>>> # apachectl -t -D DUMP_MODULES
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>> proxy_module (shared)
>>>>>>>>>>>>>>>>>>>>>>>>> proxy_http_module (shared)
>>>>>>>>>>>>>>>>>>>>>>>>> proxy_wstunnel_module (shared)
>>>>>>>>>>>>>>>>>>>>>>>>> rewrite_module (shared)
>>>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>>> Syntax OK
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Any debugging advice?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Your help will be much appreciated and will allow
>>>>>>>>>>>>>>>>>>>>>>>>> to move forward with our isntallation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Dmitry Duplyakin
>>>>>>>>>>>>>>>>>>>>>>>>> PhD student, CS at University of Colorado - Boulder
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Please keep messages on-topic and check the
>>>>>>>>>>>>>>>>>>>>>>>>> ParaView Wiki at:
>>>>>>>>>>>>>>>>>>>>>>>>> http://paraview.org/Wiki/ParaView
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140722/5dd9bdb0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 26169 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140722/5dd9bdb0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 154565 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140722/5dd9bdb0/attachment-0003.png>
More information about the ParaView
mailing list