View Issue Details Jump to Notes ] Print ]
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 
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.

 
TagsNo tags attached.
ProjectSandia
Topic Name0014732_fix_server_resource_naming
Typecrash
Attached Files

 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.

 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


Copyright © 2000 - 2018 MantisBT Team