Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-15 Thread Fabian, Nathan
I learned something new!

Although I don't now how I managed to enable it, that was the problem.  Thanks.

From: , W Alan mailto:wasc...@sandia.gov>>
Date: Tuesday, January 14, 2014 6:59 PM
To: Nathan Fabian mailto:ndfa...@sandia.gov>>, Utkarsh 
Ayachit mailto:utkarsh.ayac...@kitware.com>>
Cc: "paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: RE: [Paraview] [EXTERNAL] Client/Server connection problems

You compiled it in?

 '-DPARAVIEW_ALWAYS_SECURE_CONNECTION:BOOL=ON '

From: Fabian, Nathan
Sent: Tuesday, January 14, 2014 5:41 PM
To: Fabian, Nathan; Utkarsh Ayachit; Scott, W Alan
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Okay, I figured it out, although I'm still confused.  Resolution add 
-connect_id to both cluster and desktop.

The cluster reverse connecting was handshaking with an appended connect_id.  I 
had initially tried not using a connect_id, but it errors out saying it's 
required.

The desktop doesn't have one, unless I add it in on the command line run.

Any idea why the server is requiring one?  Also is there a way to add in the 
connect_id through the GUI as opposed to through the command line?

Thanks,

From: , Nathan Fabian mailto:ndfa...@sandia.gov>>
Date: Monday, January 13, 2014 5:42 PM
To: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>, "Scott, W 
Alan" mailto:wasc...@sandia.gov>>
Cc: "paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Thanks for the tip.  I'll try this out and let you know how it goes.

From: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>
Date: Saturday, January 11, 2014 7:43 AM
To: "Scott, W Alan" mailto:wasc...@sandia.gov>>
Cc: Nathan Fabian mailto:ndfa...@sandia.gov>>, 
"paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Nathan,

First, let me clarify what is "checked", since what Alan said isn't entirely 
correct.

What comprises the handshake?


The handshake is a string of the following form:
 paraview..
If a connect-id is specified then the handshake becomes:
 paraview...connect_id.

The client and the root-server node exchange these strings. If either side 
concludes that they don't match, the connection is terminated.
To debug, you can put a "cout" in 
vtkTCPNetworkAccessManager::ConnectToRemove(), or 
vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides 
to print the relevant string.

How is the MajorNumber/MinorNumber determined?
=

First, it's hardcoded in the top level CMakeLists.txt. Any time a version 
number changes, this is manually updated. So on "git/master", this will change 
when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release 
the version number has changed. This could explain why two builds from "git 
master" may not always work with each other.

Secondly, if the source repository is a git repository (nothing to do with 
whether it has access to the Internet), then the version is determined by using 
the git command "git describe". By making sure we "tag" the repository when the 
CMakeLists.txt change happens, we ensure that "git describe" results in version 
numbers of the form ".--". We can ignore 
FOO/BAR for now. These are extra annotations that us determine exactly what  
source version you're using, esp when doing git/master builds.

The thing to note is that the handshake only uses the  and 
. So even if your git/master checkouts are from slightly different 
points in history, they can work together (unless of course, the two checkout 
happened to be across a version number change).

Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and 
comparing the handshake strings would be a good start to debug this.

Utkarsh


On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan 
mailto:wasc...@sandia.gov>> wrote:
Then no, that isn't the issue.

One more thing to try - and I don't completely know how to do it.  (i.e., ask 
Kitware).  I believe that they now look at not just ParaView version numbers, 
but also git checkin "tags" or whatever it is called.  If the two trees are 
basically the same, and ANYONE touched the tree between pulls, that is your 
problem.  This has been an issue for me when one of the two (client or server) 
is behind a firewall, but the other can connect back to Kitware and find that 
git tag.  Make sure the source trees are exactly the same.

Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-14 Thread Scott, W Alan
You compiled it in?

 '-DPARAVIEW_ALWAYS_SECURE_CONNECTION:BOOL=ON '

From: Fabian, Nathan
Sent: Tuesday, January 14, 2014 5:41 PM
To: Fabian, Nathan; Utkarsh Ayachit; Scott, W Alan
Cc: paraview@paraview.org
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Okay, I figured it out, although I'm still confused.  Resolution add 
-connect_id to both cluster and desktop.

The cluster reverse connecting was handshaking with an appended connect_id.  I 
had initially tried not using a connect_id, but it errors out saying it's 
required.

The desktop doesn't have one, unless I add it in on the command line run.

Any idea why the server is requiring one?  Also is there a way to add in the 
connect_id through the GUI as opposed to through the command line?

Thanks,

From: , Nathan Fabian mailto:ndfa...@sandia.gov>>
Date: Monday, January 13, 2014 5:42 PM
To: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>, "Scott, W 
Alan" mailto:wasc...@sandia.gov>>
Cc: "paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Thanks for the tip.  I'll try this out and let you know how it goes.

From: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>
Date: Saturday, January 11, 2014 7:43 AM
To: "Scott, W Alan" mailto:wasc...@sandia.gov>>
Cc: Nathan Fabian mailto:ndfa...@sandia.gov>>, 
"paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Nathan,

First, let me clarify what is "checked", since what Alan said isn't entirely 
correct.

What comprises the handshake?


The handshake is a string of the following form:
 paraview..
If a connect-id is specified then the handshake becomes:
 paraview...connect_id.

The client and the root-server node exchange these strings. If either side 
concludes that they don't match, the connection is terminated.
To debug, you can put a "cout" in 
vtkTCPNetworkAccessManager::ConnectToRemove(), or 
vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides 
to print the relevant string.

How is the MajorNumber/MinorNumber determined?
=

First, it's hardcoded in the top level CMakeLists.txt. Any time a version 
number changes, this is manually updated. So on "git/master", this will change 
when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release 
the version number has changed. This could explain why two builds from "git 
master" may not always work with each other.

Secondly, if the source repository is a git repository (nothing to do with 
whether it has access to the Internet), then the version is determined by using 
the git command "git describe". By making sure we "tag" the repository when the 
CMakeLists.txt change happens, we ensure that "git describe" results in version 
numbers of the form ".--". We can ignore 
FOO/BAR for now. These are extra annotations that us determine exactly what  
source version you're using, esp when doing git/master builds.

The thing to note is that the handshake only uses the  and 
. So even if your git/master checkouts are from slightly different 
points in history, they can work together (unless of course, the two checkout 
happened to be across a version number change).

Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and 
comparing the handshake strings would be a good start to debug this.

Utkarsh


On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan 
mailto:wasc...@sandia.gov>> wrote:
Then no, that isn't the issue.

One more thing to try - and I don't completely know how to do it.  (i.e., ask 
Kitware).  I believe that they now look at not just ParaView version numbers, 
but also git checkin "tags" or whatever it is called.  If the two trees are 
basically the same, and ANYONE touched the tree between pulls, that is your 
problem.  This has been an issue for me when one of the two (client or server) 
is behind a firewall, but the other can connect back to Kitware and find that 
git tag.  Make sure the source trees are exactly the same.

Alan

-Original Message-
From: Fabian, Nathan
Sent: Friday, January 10, 2014 4:57 PM
To: Scott, W Alan; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems

That sounded promising, but it doesn't appear to have worked.  I deleted 
everything under .config/ParaView and .config/Kitware on both machines, still 
getting the same error.

On 1/10/14 4:45 PM, "Scott, W Alan" 
mailto:wasc...@sandia.gov>> wrote:

>Delete you

Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-14 Thread Fabian, Nathan
Okay, I figured it out, although I'm still confused.  Resolution add 
-connect_id to both cluster and desktop.

The cluster reverse connecting was handshaking with an appended connect_id.  I 
had initially tried not using a connect_id, but it errors out saying it's 
required.

The desktop doesn't have one, unless I add it in on the command line run.

Any idea why the server is requiring one?  Also is there a way to add in the 
connect_id through the GUI as opposed to through the command line?

Thanks,

From: , Nathan Fabian mailto:ndfa...@sandia.gov>>
Date: Monday, January 13, 2014 5:42 PM
To: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>, "Scott, W 
Alan" mailto:wasc...@sandia.gov>>
Cc: "paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Thanks for the tip.  I'll try this out and let you know how it goes.

From: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>
Date: Saturday, January 11, 2014 7:43 AM
To: "Scott, W Alan" mailto:wasc...@sandia.gov>>
Cc: Nathan Fabian mailto:ndfa...@sandia.gov>>, 
"paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Nathan,

First, let me clarify what is "checked", since what Alan said isn't entirely 
correct.

What comprises the handshake?


The handshake is a string of the following form:
 paraview..
If a connect-id is specified then the handshake becomes:
 paraview...connect_id.

The client and the root-server node exchange these strings. If either side 
concludes that they don't match, the connection is terminated.
To debug, you can put a "cout" in 
vtkTCPNetworkAccessManager::ConnectToRemove(), or 
vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides 
to print the relevant string.

How is the MajorNumber/MinorNumber determined?
=

First, it's hardcoded in the top level CMakeLists.txt. Any time a version 
number changes, this is manually updated. So on "git/master", this will change 
when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release 
the version number has changed. This could explain why two builds from "git 
master" may not always work with each other.

Secondly, if the source repository is a git repository (nothing to do with 
whether it has access to the Internet), then the version is determined by using 
the git command "git describe". By making sure we "tag" the repository when the 
CMakeLists.txt change happens, we ensure that "git describe" results in version 
numbers of the form ".--". We can ignore 
FOO/BAR for now. These are extra annotations that us determine exactly what  
source version you're using, esp when doing git/master builds.

The thing to note is that the handshake only uses the  and 
. So even if your git/master checkouts are from slightly different 
points in history, they can work together (unless of course, the two checkout 
happened to be across a version number change).

Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and 
comparing the handshake strings would be a good start to debug this.

Utkarsh



On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan 
mailto:wasc...@sandia.gov>> wrote:
Then no, that isn't the issue.

One more thing to try - and I don't completely know how to do it.  (i.e., ask 
Kitware).  I believe that they now look at not just ParaView version numbers, 
but also git checkin "tags" or whatever it is called.  If the two trees are 
basically the same, and ANYONE touched the tree between pulls, that is your 
problem.  This has been an issue for me when one of the two (client or server) 
is behind a firewall, but the other can connect back to Kitware and find that 
git tag.  Make sure the source trees are exactly the same.

Alan

-Original Message-
From: Fabian, Nathan
Sent: Friday, January 10, 2014 4:57 PM
To: Scott, W Alan; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems

That sounded promising, but it doesn't appear to have worked.  I deleted 
everything under .config/ParaView and .config/Kitware on both machines, still 
getting the same error.

On 1/10/14 4:45 PM, "Scott, W Alan" 
mailto:wasc...@sandia.gov>> wrote:

>Delete your configuration files.  Corrupt configuration files sometimes
>cause this.  Surprisingly, on one client of mine, the first connect
>works, the configuration file gets written, and you never get another
>successful connect using that configuration file.
>
>I haven't chased 

Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-13 Thread Fabian, Nathan
Thanks for the tip.  I'll try this out and let you know how it goes.

From: Utkarsh Ayachit 
mailto:utkarsh.ayac...@kitware.com>>
Date: Saturday, January 11, 2014 7:43 AM
To: "Scott, W Alan" mailto:wasc...@sandia.gov>>
Cc: Nathan Fabian mailto:ndfa...@sandia.gov>>, 
"paraview@paraview.org<mailto:paraview@paraview.org>" 
mailto:paraview@paraview.org>>
Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems

Nathan,

First, let me clarify what is "checked", since what Alan said isn't entirely 
correct.

What comprises the handshake?


The handshake is a string of the following form:
 paraview..
If a connect-id is specified then the handshake becomes:
 paraview...connect_id.

The client and the root-server node exchange these strings. If either side 
concludes that they don't match, the connection is terminated.
To debug, you can put a "cout" in 
vtkTCPNetworkAccessManager::ConnectToRemove(), or 
vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides 
to print the relevant string.

How is the MajorNumber/MinorNumber determined?
=

First, it's hardcoded in the top level CMakeLists.txt. Any time a version 
number changes, this is manually updated. So on "git/master", this will change 
when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release 
the version number has changed. This could explain why two builds from "git 
master" may not always work with each other.

Secondly, if the source repository is a git repository (nothing to do with 
whether it has access to the Internet), then the version is determined by using 
the git command "git describe". By making sure we "tag" the repository when the 
CMakeLists.txt change happens, we ensure that "git describe" results in version 
numbers of the form ".--". We can ignore 
FOO/BAR for now. These are extra annotations that us determine exactly what  
source version you're using, esp when doing git/master builds.

The thing to note is that the handshake only uses the  and 
. So even if your git/master checkouts are from slightly different 
points in history, they can work together (unless of course, the two checkout 
happened to be across a version number change).

Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and 
comparing the handshake strings would be a good start to debug this.

Utkarsh



On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan 
mailto:wasc...@sandia.gov>> wrote:
Then no, that isn't the issue.

One more thing to try - and I don't completely know how to do it.  (i.e., ask 
Kitware).  I believe that they now look at not just ParaView version numbers, 
but also git checkin "tags" or whatever it is called.  If the two trees are 
basically the same, and ANYONE touched the tree between pulls, that is your 
problem.  This has been an issue for me when one of the two (client or server) 
is behind a firewall, but the other can connect back to Kitware and find that 
git tag.  Make sure the source trees are exactly the same.

Alan

-Original Message-
From: Fabian, Nathan
Sent: Friday, January 10, 2014 4:57 PM
To: Scott, W Alan; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems

That sounded promising, but it doesn't appear to have worked.  I deleted 
everything under .config/ParaView and .config/Kitware on both machines, still 
getting the same error.

On 1/10/14 4:45 PM, "Scott, W Alan" 
mailto:wasc...@sandia.gov>> wrote:

>Delete your configuration files.  Corrupt configuration files sometimes
>cause this.  Surprisingly, on one client of mine, the first connect
>works, the configuration file gets written, and you never get another
>successful connect using that configuration file.
>
>I haven't chased this down yes, hoping it goes away with the new version.
> But...
>
>If this is the problem, please let me know.  You may have an easier
>setup that we can use to get to the root cause of the problem.
>
>Alan
>
>-Original Message-
>From: paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>
>[mailto:paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>] 
>On Behalf Of Fabian, Nathan
>Sent: Friday, January 10, 2014 3:59 PM
>To: paraview@paraview.org<mailto:paraview@paraview.org>
>Subject: [EXTERNAL] [Paraview] Client/Server connection problems
>
>Hi,
>
>I've been trying to figure this one out for a few days and I'm finally
>giving in for help.
>
>I've got a code base on my server that should be a duplicate of the one
>on my desktop, built differently.  In one case I did pulls from m

Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-11 Thread Utkarsh Ayachit
Nathan,

First, let me clarify what is "checked", since what Alan said isn't
entirely correct.

What comprises the handshake?


The handshake is a string of the following form:
 paraview..
If a connect-id is specified then the handshake becomes:
 paraview...connect_id.

The client and the root-server node exchange these strings. If either side
concludes that they don't match, the connection is terminated.
To debug, you can put a "cout" in
vtkTCPNetworkAccessManager::ConnectToRemove(), or
vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either)
sides to print the relevant string.

How is the MajorNumber/MinorNumber determined?
=

First, it's hardcoded in the top level CMakeLists.txt. Any time a version
number changes, this is manually updated. So on "git/master", this will
change when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the
official release the version number has changed. This could explain why two
builds from "git master" may not always work with each other.

Secondly, if the source repository is a git repository (nothing to do with
whether it has access to the Internet), then the version is determined by
using the git command "git describe". By making sure we "tag" the
repository when the CMakeLists.txt change happens, we ensure that "git
describe" results in version numbers of the form
".--". We can ignore FOO/BAR for now.
These are extra annotations that us determine exactly what  source version
you're using, esp when doing git/master builds.

The thing to note is that the handshake only uses the  and
. So even if your git/master checkouts are from slightly
different points in history, they can work together (unless of course, the
two checkout happened to be across a version number change).

Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager
and comparing the handshake strings would be a good start to debug this.

Utkarsh



On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan  wrote:

> Then no, that isn't the issue.
>
> One more thing to try - and I don't completely know how to do it.  (i.e.,
> ask Kitware).  I believe that they now look at not just ParaView version
> numbers, but also git checkin "tags" or whatever it is called.  If the two
> trees are basically the same, and ANYONE touched the tree between pulls,
> that is your problem.  This has been an issue for me when one of the two
> (client or server) is behind a firewall, but the other can connect back to
> Kitware and find that git tag.  Make sure the source trees are exactly the
> same.
>
> Alan
>
> -Original Message-
> From: Fabian, Nathan
> Sent: Friday, January 10, 2014 4:57 PM
> To: Scott, W Alan; paraview@paraview.org
> Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems
>
> That sounded promising, but it doesn't appear to have worked.  I deleted
> everything under .config/ParaView and .config/Kitware on both machines,
> still getting the same error.
>
> On 1/10/14 4:45 PM, "Scott, W Alan"  wrote:
>
> >Delete your configuration files.  Corrupt configuration files sometimes
> >cause this.  Surprisingly, on one client of mine, the first connect
> >works, the configuration file gets written, and you never get another
> >successful connect using that configuration file.
> >
> >I haven't chased this down yes, hoping it goes away with the new version.
> > But...
> >
> >If this is the problem, please let me know.  You may have an easier
> >setup that we can use to get to the root cause of the problem.
> >
> >Alan
> >
> >-Original Message-
> >From: paraview-boun...@paraview.org
> >[mailto:paraview-boun...@paraview.org] On Behalf Of Fabian, Nathan
> >Sent: Friday, January 10, 2014 3:59 PM
> >To: paraview@paraview.org
> >Subject: [EXTERNAL] [Paraview] Client/Server connection problems
> >
> >Hi,
> >
> >I've been trying to figure this one out for a few days and I'm finally
> >giving in for help.
> >
> >I've got a code base on my server that should be a duplicate of the one
> >on my desktop, built differently.  In one case I did pulls from master
> >at the same time.  I've more recently just tried pulling directly from
> >my desktop and building clean on both.  I've also tried disabling MPI
> >on the desktop side and connecting without MPI on the server side.
> >
> >Still I'm getting the following message when trying to reverse connect:
> >
> >
> >ERROR: In
> >/projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkT
> >CPN
> >e
> >tworkAccessManager.cxx, line 330
> >vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to
> >xyz.sandia.gov:1. Client-Server Handshake failed. Please verify
> >that the client and server versions are compatible with each other, and
> >that 'connect-id', if any, matches.
> >
> >
> >And then each attempt to connect gives this on the desktop:
> >
> >
> >
> >Accepting connection(s): xyz.sandia.gov:1
> >
> >
> >Evidence that some sort of communicat

Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-10 Thread Scott, W Alan
Then no, that isn't the issue.

One more thing to try - and I don't completely know how to do it.  (i.e., ask 
Kitware).  I believe that they now look at not just ParaView version numbers, 
but also git checkin "tags" or whatever it is called.  If the two trees are 
basically the same, and ANYONE touched the tree between pulls, that is your 
problem.  This has been an issue for me when one of the two (client or server) 
is behind a firewall, but the other can connect back to Kitware and find that 
git tag.  Make sure the source trees are exactly the same.

Alan

-Original Message-
From: Fabian, Nathan 
Sent: Friday, January 10, 2014 4:57 PM
To: Scott, W Alan; paraview@paraview.org
Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems

That sounded promising, but it doesn't appear to have worked.  I deleted 
everything under .config/ParaView and .config/Kitware on both machines, still 
getting the same error.

On 1/10/14 4:45 PM, "Scott, W Alan"  wrote:

>Delete your configuration files.  Corrupt configuration files sometimes 
>cause this.  Surprisingly, on one client of mine, the first connect 
>works, the configuration file gets written, and you never get another 
>successful connect using that configuration file.
>
>I haven't chased this down yes, hoping it goes away with the new version.
> But...
>
>If this is the problem, please let me know.  You may have an easier 
>setup that we can use to get to the root cause of the problem.
>
>Alan
>
>-Original Message-
>From: paraview-boun...@paraview.org
>[mailto:paraview-boun...@paraview.org] On Behalf Of Fabian, Nathan
>Sent: Friday, January 10, 2014 3:59 PM
>To: paraview@paraview.org
>Subject: [EXTERNAL] [Paraview] Client/Server connection problems
>
>Hi,
>
>I've been trying to figure this one out for a few days and I'm finally 
>giving in for help.
>
>I've got a code base on my server that should be a duplicate of the one 
>on my desktop, built differently.  In one case I did pulls from master 
>at the same time.  I've more recently just tried pulling directly from 
>my desktop and building clean on both.  I've also tried disabling MPI 
>on the desktop side and connecting without MPI on the server side.
>
>Still I'm getting the following message when trying to reverse connect:
>
>
>ERROR: In
>/projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkT
>CPN
>e
>tworkAccessManager.cxx, line 330
>vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to 
>xyz.sandia.gov:1. Client-Server Handshake failed. Please verify 
>that the client and server versions are compatible with each other, and 
>that 'connect-id', if any, matches.
>
>
>And then each attempt to connect gives this on the desktop:
>
>
>
>Accepting connection(s): xyz.sandia.gov:1
>
>
>Evidence that some sort of communication has worked.  This has worked 
>with master builds in the past.  I'm not sure what I changed, but 
>there's plenty I have that may have influenced this.
>
>Any suggestions on where to start looking?
>
>Thanks,
>Nathan.
>
>___
>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://www.paraview.org/mailman/listinfo/paraview

___
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://www.paraview.org/mailman/listinfo/paraview


Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-10 Thread Fabian, Nathan
That sounded promising, but it doesn't appear to have worked.  I deleted
everything under .config/ParaView and .config/Kitware on both machines,
still getting the same error.

On 1/10/14 4:45 PM, "Scott, W Alan"  wrote:

>Delete your configuration files.  Corrupt configuration files sometimes
>cause this.  Surprisingly, on one client of mine, the first connect
>works, the configuration file gets written, and you never get another
>successful connect using that configuration file.
>
>I haven't chased this down yes, hoping it goes away with the new version.
> But...
>
>If this is the problem, please let me know.  You may have an easier setup
>that we can use to get to the root cause of the problem.
>
>Alan
>
>-Original Message-
>From: paraview-boun...@paraview.org
>[mailto:paraview-boun...@paraview.org] On Behalf Of Fabian, Nathan
>Sent: Friday, January 10, 2014 3:59 PM
>To: paraview@paraview.org
>Subject: [EXTERNAL] [Paraview] Client/Server connection problems
>
>Hi,
>
>I've been trying to figure this one out for a few days and I'm finally
>giving in for help.
>
>I've got a code base on my server that should be a duplicate of the one
>on my desktop, built differently.  In one case I did pulls from master at
>the same time.  I've more recently just tried pulling directly from my
>desktop and building clean on both.  I've also tried disabling MPI on the
>desktop side and connecting without MPI on the server side.
>
>Still I'm getting the following message when trying to reverse connect:
>
>
>ERROR: In
>/projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPN
>e
>tworkAccessManager.cxx, line 330
>vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to
>xyz.sandia.gov:1. Client-Server Handshake failed. Please verify that
>the client and server versions are compatible with each other, and that
>'connect-id', if any, matches.
>
>
>And then each attempt to connect gives this on the desktop:
>
>
>
>Accepting connection(s): xyz.sandia.gov:1
>
>
>Evidence that some sort of communication has worked.  This has worked with
>master builds in the past.  I'm not sure what I changed, but there's
>plenty I have that may have influenced this.
>
>Any suggestions on where to start looking?
>
>Thanks,
>Nathan.
>
>___
>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://www.paraview.org/mailman/listinfo/paraview

___
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://www.paraview.org/mailman/listinfo/paraview


Re: [Paraview] [EXTERNAL] Client/Server connection problems

2014-01-10 Thread Scott, W Alan
Delete your configuration files.  Corrupt configuration files sometimes cause 
this.  Surprisingly, on one client of mine, the first connect works, the 
configuration file gets written, and you never get another successful connect 
using that configuration file.

I haven't chased this down yes, hoping it goes away with the new version.  
But...

If this is the problem, please let me know.  You may have an easier setup that 
we can use to get to the root cause of the problem.

Alan

-Original Message-
From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On 
Behalf Of Fabian, Nathan
Sent: Friday, January 10, 2014 3:59 PM
To: paraview@paraview.org
Subject: [EXTERNAL] [Paraview] Client/Server connection problems

Hi,

I've been trying to figure this one out for a few days and I'm finally giving 
in for help.

I've got a code base on my server that should be a duplicate of the one on my 
desktop, built differently.  In one case I did pulls from master at the same 
time.  I've more recently just tried pulling directly from my desktop and 
building clean on both.  I've also tried disabling MPI on the desktop side and 
connecting without MPI on the server side.

Still I'm getting the following message when trying to reverse connect:


ERROR: In
/projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPNe
tworkAccessManager.cxx, line 330
vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to 
xyz.sandia.gov:1. Client-Server Handshake failed. Please verify that the 
client and server versions are compatible with each other, and that 
'connect-id', if any, matches.


And then each attempt to connect gives this on the desktop:



Accepting connection(s): xyz.sandia.gov:1


Evidence that some sort of communication has worked.  This has worked with
master builds in the past.  I'm not sure what I changed, but there's
plenty I have that may have influenced this.

Any suggestions on where to start looking?

Thanks,
Nathan.

___
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://www.paraview.org/mailman/listinfo/paraview
___
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://www.paraview.org/mailman/listinfo/paraview