[Paraview] Help with web proxy
CLSA Mcmaster
clsamcmaster at gmail.com
Thu Jun 19 12:27:16 EDT 2014
Almost there. Got it to load.
On Jun 19, 2014 10:57 AM, "Sebastien Jourdain" <
sebastien.jourdain at kitware.com> wrote:
> Hi Sean,
>
> if you have a user logged in with a "DISPLAY", you just need to run
> "export DISPLAY=:0.0" before running your launcher.
> So when your launcher trigger a new viz job, it inherits that property.
>
> You can try again with your command line and see if you get the same error
> when you export the display first.
>
> But anyhow, you need a GPU and a X session running. And make sure you have
> the latest drivers as well for better performances.
>
> Otherwise, if you don't have a GPU, then you will need to build ParaView
> with OS Mesa.
>
> Seb
>
>
> On Thu, Jun 19, 2014 at 7:44 AM, CLSA Mcmaster <clsamcmaster at gmail.com>
> wrote:
>
>> Hello
>>
>> I think I have found the problem. When I run the launcher from the CLI as
>> follows:
>>
>> pvpython
>> /data/pvw/paraview/lib/paraview-4.1/site-packages/paraview/web/pv_web_visualizer.py
>> -d --content /data/pvw/www --data-dir /data/pvw/data --port 8080
>>
>> And then access the URL I get the following error:
>>
>> [19/Jun/2014:13:37:10 +0000] "POST /paraview/ HTTP/1.1" 404 145 "
>> http://paraview.domain.ca:8080/apps/Visualizer/" "Mozilla/5.0 (Windows
>> NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
>> ERROR: In
>> /usr/local/src/paraview/4.1.0/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
>> line 531
>> vtkXOpenGLRenderWindow (0x328b7c0): bad X server connection.
>> DISPLAY=Aborted (core dumped)
>>
>> I'm not sure why I don't see this error or generate a core dump when
>> using the configuration file.
>>
>> In any case, we are using the 64bit binaries for Linux (Ubuntu 14.04). Do
>> we need to compile our own Paraview 4.1? We are having difficulty compiling
>> OSMesa support due to missing libraries.
>>
>> Thanks, again.
>>
>> Sean.
>>
>>
>>
>> On Wed, Jun 18, 2014 at 10:44 AM, CLSA Mcmaster <clsamcmaster at gmail.com>
>> wrote:
>>
>>> Hello Sebastien
>>>
>>> Thank you for the very quick reply.
>>>
>>> I am following this document:
>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/#!/guide/ubuntu_14_04
>>>
>>> I am using paraview version 4.1.0.
>>>
>>> I get the same result if I go directly to port 8080. I am running in
>>> debug mode but I am not seeing anything at all helpful. Firebug shows me:
>>>
>>> {"id": "103b792a-f6ee-11e3-b1d5-14feb5ee4ae2", "host": "paraview.domain.ca", "port": 9103, "sessionManagerURL":
>>>
>>>
>>>
>>> "http://paraview.domain.ca:8080/paraview/", "sessionURL":
>>> "ws://paraview.domain.ca/proxy?sessionId=103b792a-f6ee-11e3-b1d5-14feb5ee4ae2"}
>>>
>>> Followed by:
>>>
>>> Firefox can't establish a connection to the server at ws://
>>> paraview.mcmaster.ca/proxy?sessionId=103b792a-f6ee-11e3-b1d5-14feb5ee4ae2
>>> .
>>>
>>> My Apache config is as follows:
>>>
>>> <VirtualHost *:80>
>>> ServerAlias paraview.domain.ca
>>> ServerAdmin webmaster at domain.ca
>>> DocumentRoot /data/pvw/www
>>>
>>> ErrorLog /data/logs/error.log
>>> CustomLog /data/logs/access.log combined
>>>
>>> # Handle launcher forwarding
>>> ProxyPass /paraview http://dragonfly.domain.ca:8080/paraview
>>>
>>> # Handle WebSocket forwarding
>>> RewriteEngine On
>>> RewriteMap session-to-port txt:/data/proxy.txt
>>> RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
>>> RewriteRule ^/proxy.*$ ws://${session-to-port:%1}/ws [P]
>>>
>>> <Directory "/data/pvw/www">
>>> Options Indexes FollowSymLinks
>>> Order allow,deny
>>> Allow from all
>>> AllowOverride all
>>> Require all granted
>>> </Directory>
>>>
>>> </VirtualHost>
>>>
>>> And the launcher.py config file:
>>>
>>> {"configuration":
>>> {"content":
>>> "/data/pvw/www",
>>> "log_dir": "/data/pvw/logs",
>>> "host": "192.168.1.110",
>>> "endpoint": "paraview",
>>> "sessionURL": "ws://paraview.domain.ca:8080/",
>>> "timeout": 5,
>>> "upload_dir": "/data/pvw/data",
>>> "fields": ["file", "host", "port", "updir"], "port":
>>> 8080,
>>> "proxy_file": "/data/pvw/conf/proxy.conf"},
>>> "apps": {"data_prober": {"cmd": ["${python_exec}",
>>> "${python_path}/paraview/web/pv_web_data_prober.py",
>>> "--port", "${port}", "--data-dir", "${data}"]},
>>> "pipeline": {"cmd": ["${python_exec}",
>>> "${python_path}/paraview/web/pv_web_visualizer.py",
>>> "--port", "${port}", "--data-dir", "${data}"]},
>>> "loader": {"cmd": ["${python_exec}",
>>> "${python_path}/paraview/web/pv_web_file_loader.py",
>>> "--port", "${port}", "--data-dir", "${data}"] }
>>> },
>>> "properties":
>>> {"python_path":
>>> "/data/pvw/paraview/lib/paraview-4.1/site-packages/",
>>> "data": "/data/pvw/data",
>>> "python_exec": "/data/pvw/paraview/bin/pvpython"
>>> },
>>> "resources":
>>> [{"port_range": [9001, 9003], "host": "192.168.1.110"}],
>>> "sessionData": {"updir": "/Home"}
>>> }
>>>
>>>
>>> One thing I've noticed is that different config files show either
>>> ${data} or ${dataDIR} but I do not see these variables defined anywhere.
>>>
>>> But other than that, I'm stumped.
>>>
>>> Thanks, once more, for your help.
>>>
>>> Sean.
>>>
>>>
>>> On Tue, Jun 17, 2014 at 3:35 PM, Sebastien Jourdain <
>>> sebastien.jourdain at kitware.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm not sure to understand that error either.
>>>>
>>>> Which setup did you followed? Which version of ParaView are you using?
>>>> (release/master)
>>>>
>>>> Did you try with a direct connection without apache in the middle? Does
>>>> that work?
>>>>
>>>> If so what is your apache setup and launcher.py configuration file?
>>>>
>>>> Any guidance on your setup may help.
>>>>
>>>> Seb
>>>>
>>>>
>>>> On Tue, Jun 17, 2014 at 12:21 PM, CLSA Mcmaster <clsamcmaster at gmail.com
>>>> > wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> I feel I am very close to getting this but I need some help.
>>>>>
>>>>> I am using Paraview with Python and an Apache front end with proxying.
>>>>> My logs show as follows:
>>>>>
>>>>> [Tue Jun 17 14:18:34.353847 2014] [proxy:debug] [pid 5840]
>>>>> proxy_util.c(2035): AH00943: http: has released connection for (
>>>>> dragonfly.domain.ca)
>>>>> [Tue Jun 17 14:18:34.353905 2014] [deflate:debug] [pid 5840]
>>>>> mod_deflate.c(764): [client 192.168.1.9:45352] AH01384: Zlib:
>>>>> Compressed 246 to 151 : URL /paraview/, referer:
>>>>> http://paraview.domain.ca/apps/FileViewer/
>>>>> [Tue Jun 17 14:18:34.366482 2014] [authz_core:debug] [pid 5843]
>>>>> mod_authz_core.c(828): [client 192.168.1.9:45354] AH01628:
>>>>> authorization result: granted (no directives)
>>>>> [Tue Jun 17 14:18:34.366557 2014] [proxy:debug] [pid 5843]
>>>>> mod_proxy.c(1104): [client 192.168.1.9:45354] AH01143: Running scheme
>>>>> ws handler (attempt 0)
>>>>> [Tue Jun 17 14:18:34.366566 2014] [proxy_ajp:debug] [pid 5843]
>>>>> mod_proxy_ajp.c(708): [client 192.168.1.9:45354] AH00894: declining
>>>>> URL ws://
>>>>> 192.168.1.110:9103/ws?sessionId=c83abd36-f64b-11e3-b1d5-14feb5ee4ae2
>>>>> [Tue Jun 17 14:18:34.366577 2014] [proxy_http:debug] [pid 5843]
>>>>> mod_proxy_http.c(1892): [client 192.168.1.9:45354] AH01113: HTTP:
>>>>> declining URL ws://
>>>>> 192.168.1.110:9103/ws?sessionId=c83abd36-f64b-11e3-b1d5-14feb5ee4ae2
>>>>> [Tue Jun 17 14:18:34.366583 2014] [proxy_wstunnel:debug] [pid 5843]
>>>>> mod_proxy_wstunnel.c(331): [client 192.168.1.9:45354] AH02451:
>>>>> serving URL ws://
>>>>> 192.168.1.110:9103/ws?sessionId=c83abd36-f64b-11e3-b1d5-14feb5ee4ae2
>>>>> [Tue Jun 17 14:18:34.366590 2014] [proxy:debug] [pid 5843]
>>>>> proxy_util.c(2020): AH00942: WS: has acquired connection for (*)
>>>>> [Tue Jun 17 14:18:34.366596 2014] [proxy:debug] [pid 5843]
>>>>> proxy_util.c(2072): [client 192.168.1.9:45354] AH00944: connecting
>>>>> ws://
>>>>> 192.168.1.110:9103/ws?sessionId=c83abd36-f64b-11e3-b1d5-14feb5ee4ae2
>>>>> to 192.168.1.110:9103
>>>>> [Tue Jun 17 14:18:34.366665 2014] [proxy:debug] [pid 5843]
>>>>> proxy_util.c(2206): [client 192.168.1.9:45354] AH00947: connected
>>>>> /ws?sessionId=c83abd36-f64b-11e3-b1d5-14feb5ee4ae2 to
>>>>> 192.168.1.110:9103
>>>>> [Tue Jun 17 14:18:34.366800 2014] [proxy:debug] [pid 5843]
>>>>> proxy_util.c(2610): AH00962: WS: connection complete to
>>>>> 192.168.1.110:9103 (192.168.1.110)
>>>>> [Tue Jun 17 14:18:34.574643 2014] [proxy_wstunnel:debug] [pid 5843]
>>>>> mod_proxy_wstunnel.c(253): [client 192.168.1.9:45354] AH02445: woke
>>>>> from poll(), i=1
>>>>> [Tue Jun 17 14:18:34.574681 2014] [proxy_wstunnel:debug] [pid 5843]
>>>>> mod_proxy_wstunnel.c(262): [client 192.168.1.9:45354] AH02446: sock
>>>>> was readable
>>>>> [Tue Jun 17 14:18:34.574725 2014] [proxy_wstunnel:debug] [pid 5843]
>>>>> mod_proxy_wstunnel.c(129): (104)Connection reset by peer: [client
>>>>> 192.168.1.9:45354] AH02442: error on sock - ap_get_brigade
>>>>> [Tue Jun 17 14:18:34.574751 2014] [proxy:debug] [pid 5843]
>>>>> proxy_util.c(2035): AH00943: WS: has released connection for (*)
>>>>>
>>>>> As you can see, I am getting a reset by peer but I'm not sure of the
>>>>> cause. Any help or clues would be greatly appreciated.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20140619/d36e0121/attachment-0001.html>
More information about the ParaView
mailing list