View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014732 | ParaView | (No Category) | public | 2014-05-15 13:46 | 2015-09-06 12:18 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Utkarsh Ayachit | ||||||||
Priority | high | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | git-master | ||||||||
Target Version | 4.4 | Fixed in Version | 4.4 | ||||||
Summary | 0014732: .ini files on client side incorrectly hold paths to server | ||||||||
Description | Linux, 4.1.0, remote server (multiple cases) When a user does a remote connection using the GUI, the local .config/ParaView/ParaView4.1.ini file holds the remote plugins to load. This plugin list also includes hard coded paths to these remote plugin libraries. At the start of the config line, the remote server name is written, so ParaView can keep different servers straight. This logic falls down when we are doing command line connects. The ParaView*.*.ini file then includes a server name of localhost, and all different connections use this line of the .ini file. Two issues - since paths are hard coded, they may be and often are wrong between different clusters. Second, we may not have the same plugins built between different clusters. This then makes the connection hang (seems somewhat random for this hang). The workaround is to always delete the ParaView*.*.ini file before running. Since this causes a hang, I am marking this bug as a crash. | ||||||||
Tags | No tags attached. | ||||||||
Project | Sandia | ||||||||
Topic Name | 0014732_fix_server_resource_naming | ||||||||
Type | crash | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0032643) Alan Scott (manager) 2014-05-16 13:28 |
Another good writeup from the paraview e-mail list: I have multiple production machines where PV is installed, some with GPUs, some with mesa-rendering. Even so, operating systems differ on the different machines. The problem I have is that PV is installed in application directories on a filesystem shared by all production machines. And when using the auto-load feature of Manage Plugin, I often have conflicts, or even crashes when establishing a connection. For example: Wrong tag but don't know how to handle it... 188971 Aborted (core dumped) I use reverse-connection to connect to all production machines. My servers.pvsc file has multiple entries, each one looking like <Server name="Reverse-Connect-Cluster1" resource="csrc://"> ... </Server> <Server name="Reverse-Connect-Cluster2" resource="csrc://"> ... </Server> <Server name="Reverse-Connect-Cluster3" resource="csrc://"> ... </Server> what I am finding out is that my desktop init file "ParaView4.1.0.ini" remembers which plugins to auto-load based on a tag composed of "csrc://port" thus, when using the default port 11111 for all connections, I am loading the plugins referred to under "csrc://11111" regardless of the cluster's name. This causes conflicts or crashes on connecting. seems like a fix for a single user would be to always use different port numbers for each production machine. But then I don't know how to generalize this for all users in the Computing Center. Any tip on how to avoid conflicts with port numbers and reverse connection, and ensuring that auto-load works properly would be welcome. |
(0034214) Utkarsh Ayachit (administrator) 2015-02-12 09:50 |
commit d49d78ec92bc5dede65e6ca35913f2b5204bf278 Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com> Date: Wed Feb 11 17:47:44 2015 -0500 BUG 0014732: Using server configuration name in plugin settings. When saving information about loaded plugins etc., use the server configuration name, if available, when saving/loading the plugin setup to the settings. That way if multiple server configurations use the same resource url e.g. cs://localhost... but are actually different servers connected to using ssh port forwarding (for example), then the plugins across different servers don't get mixed up. Change-Id: I77ea85ad082bf0fb7e209f724cd125f50e1f8417 commit e74ee19805ec0a583a4fdc51b64568a3884aee2a Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com> Date: Wed Feb 11 17:19:44 2015 -0500 Make pqServerResource track the pqServerConfiguration. pqServerResource now tracks the pqServerConfiguration that it was born from. This makes it possible for the UI to know which configuration was used to connect to the specified server. If the pqServerResource was not created from a pqServerConfiguration e.g. when ParaView is started with -url command line argument. This change still works, since it just creates an empty/default pqServerConfiguration for such a pqServerResource. Change-Id: I14709287fedbccb0d5b041775b75a91a96461bc6 |
(0034220) Utkarsh Ayachit (administrator) 2015-02-16 10:09 |
Topics merged into master (v4.3.1-164-g7158a0b): 0014732_fix_server_resource_naming (VTK) 0015318_fix_stereo_client_server |
(0034231) Alan Scott (manager) 2015-02-18 15:16 |
I think this one is correct. Reopen if the issue remains. Tested Linux, remote server, master. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2014-05-15 13:46 | Alan Scott | New Issue | |
2014-05-16 13:28 | Alan Scott | Note Added: 0032643 | |
2014-06-09 07:14 | Utkarsh Ayachit | Product Version | 4.1 => 4.2 |
2014-09-19 20:06 | Utkarsh Ayachit | Product Version | 4.2 => 4.2.1 |
2014-09-19 22:50 | Utkarsh Ayachit | Product Version | 4.2.1 => git-master |
2014-09-19 22:50 | Utkarsh Ayachit | Target Version | => 4.2.1 |
2014-11-14 22:53 | Utkarsh Ayachit | Target Version | 4.2.1 => 4.4 |
2015-02-11 17:18 | Utkarsh Ayachit | Assigned To | => Utkarsh Ayachit |
2015-02-11 17:18 | Utkarsh Ayachit | Status | backlog => active development |
2015-02-11 17:19 | Utkarsh Ayachit | Topic Name | => 0014732_fix_server_resource_naming |
2015-02-11 17:51 | Utkarsh Ayachit | Note Added: 0034212 | |
2015-02-12 09:50 | Utkarsh Ayachit | Note Deleted: 0034212 | |
2015-02-12 09:50 | Utkarsh Ayachit | Note Added: 0034214 | |
2015-02-12 09:50 | Utkarsh Ayachit | Status | active development => gatekeeper review |
2015-02-12 09:50 | Utkarsh Ayachit | Fixed in Version | => git-next |
2015-02-12 09:50 | Utkarsh Ayachit | Resolution | open => fixed |
2015-02-16 10:09 | Utkarsh Ayachit | Fixed in Version | git-next => git-master |
2015-02-16 10:09 | Utkarsh Ayachit | Status | gatekeeper review => customer review |
2015-02-16 10:09 | Utkarsh Ayachit | Note Added: 0034220 | |
2015-02-18 15:16 | Alan Scott | Note Added: 0034231 | |
2015-02-18 15:16 | Alan Scott | Status | customer review => closed |
2015-09-06 12:18 | Utkarsh Ayachit | Fixed in Version | git-master => 4.4 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |