At server and client side I work with same architectures, operating systems and compilers: x86_64, Debian GNU/Linux 10 (buster), gcc (Debian 8.3.0-6) 8.3.0.
which all kind of relate to the same attempts to have pvserver work as expected. But they do not seem to have received an adequate answer, or I could not decipher a relationship to my specifics.
Previous activity on this forum lets me think that
Resuming this topic whereby pvserver does not work in parallel mode with reverse connection, I hope that the search reporting given above is exhaustive enough.
Elaborating on it, I have server and client clashing on this line of the subroutine vtkSocketCommunicator (namely from /superbuild/paraview/src/VTK/Parallel/Core/vtkSocketCommunicator.cxx)
What does the condition 554 imply? Is this a question for the developers? Thanks for advising. Reverse connection is the only way for me to use Paraview purposefully, alas.
First, make sure that the VTK submodule is updated on both the client and server:
git submodule update --recursive
I have forgotten to do that and run into similar connection errors.
If that doesn’t work, you can try a make clean in your build directory. If that still doesn’t work, delete everything inside the build directory and start fresh.
The --recusive option just tells the VTK submodule to update its (currently one) submodule, VTK-m, which shouldn’t make a difference with regards to the client/server handshake. But that operation should be updated in the build instructions.
I’m even more confused now. Those build instructions you’ve cited are for the superbuild, not paraview itself - --recursive is only useful when updating the paraview repository. The superbuild does have a submodule that requires updating, but it does not have nested submodules that would require the --recursive option to be passed to git submodule update. In any case, I am glad it is working for you now. I suspect maybe you had a build in a bad state and rebuilding was the actual solution.
For superbuild, I’m not sure how well make clean works in practice. make clean is always a little dicey when source code might be changing (via git submodule update, etc.) as build rules are added and deleted. It is usually safest to start from an empty build directory if you get into a “weird” state and make clean hasn’t worked.
The errors have been launched by pvserver, and both client and sever are little endian; I cannot say which potential bad build was sending a wrong endianness or reading it wrong, though. I sort of think to have launched a make clean after each rebuild attempt as a matter of habit.
However, after the git-update-submodule’s, I had to work around another issue at the client side, namely building version 5.7.0 on cluster (2). There I certain had a make clean at each attempt. So the alternative anwer could be don’t forget to make clean before rebuilding? Please add that to your answer above if applicable: there’s not much recent around about this endian-handshake glitch, and it can be useful for future readers.
Indeed, either way that issue is solved. Thanks for sparring.
@cory.quammen Would you mind it to edit your accepted answer and add that making sure to do a make clean could also be part of the solution? There are not so many tips in the internet on sorting the endian-handshake incident. A little edit can help future readers fix their problem quickly, since the solution is appended to the question. Thanks in advance.
This concludes my elaborations on this post. Thanks again for the support.