MantisBT - ParaView
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014732ParaView(No Category)public2014-05-15 13:462015-09-06 12:18
ReporterAlan Scott 
Assigned ToUtkarsh Ayachit 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versiongit-master 
Target Version4.4Fixed in Version4.4 
ProjectSandia
Topic Name0014732_fix_server_resource_naming
Typecrash
Summary0014732: .ini files on client side incorrectly hold paths to server
DescriptionLinux, 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.

 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-05-15 13:46Alan ScottNew Issue
2014-05-16 13:28Alan ScottNote Added: 0032643
2014-06-09 07:14Utkarsh AyachitProduct Version4.1 => 4.2
2014-09-19 20:06Utkarsh AyachitProduct Version4.2 => 4.2.1
2014-09-19 22:50Utkarsh AyachitProduct Version4.2.1 => git-master
2014-09-19 22:50Utkarsh AyachitTarget Version => 4.2.1
2014-11-14 22:53Utkarsh AyachitTarget Version4.2.1 => 4.4
2015-02-11 17:18Utkarsh AyachitAssigned To => Utkarsh Ayachit
2015-02-11 17:18Utkarsh AyachitStatusbacklog => active development
2015-02-11 17:19Utkarsh AyachitTopic Name => 0014732_fix_server_resource_naming
2015-02-11 17:51Utkarsh AyachitNote Added: 0034212
2015-02-12 09:50Utkarsh AyachitNote Deleted: 0034212
2015-02-12 09:50Utkarsh AyachitNote Added: 0034214
2015-02-12 09:50Utkarsh AyachitStatusactive development => gatekeeper review
2015-02-12 09:50Utkarsh AyachitFixed in Version => git-next
2015-02-12 09:50Utkarsh AyachitResolutionopen => fixed
2015-02-16 10:09Utkarsh AyachitFixed in Versiongit-next => git-master
2015-02-16 10:09Utkarsh AyachitStatusgatekeeper review => customer review
2015-02-16 10:09Utkarsh AyachitNote Added: 0034220
2015-02-18 15:16Alan ScottNote Added: 0034231
2015-02-18 15:16Alan ScottStatuscustomer review => closed
2015-09-06 12:18Utkarsh AyachitFixed in Versiongit-master => 4.4

Notes
(0032643)
Alan Scott   
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   
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   
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   
2015-02-18 15:16   
I think this one is correct. Reopen if the issue remains.

Tested Linux, remote server, master.