Jump to content

Cannot synchronize for replication


JakubH

Recommended Posts

We use Plastic SCM with one central server. Now, I've tried to install a local server on my machine, because I want to replicate one repository and make a private branch for some experiment in it. But when I set a sync replication, I've got following error message:

Error: There has been an unexpected error "Binary stream '0' does not contain a valid BinaryHeader. Possible causes are invalid stream or object version change between serialization and deserialization.: JAKUBH:8087". For more information check the server log.

Which is strange, because I am successfully connected to both servers from my client.
Version of my local server (and my client) is 4.1.10.397 – Tanger. Version of the central server is 4.1.10.366 – Tucuman. Could it be some incompatibility between those two?

 

Link to comment
Share on other sites

I've updated the central server to the same version (4.1.10.397 – Tanger), but the same error appears after refresh.

 

I am connecting to both servers through Profiles in Preferences, while the connection to the central server is set also in a config file (using the Client configuration wizard). I am able to use both (for example to create a repository, change permissions) except replication.

Link to comment
Share on other sites

That's pretty strange.

 

Can you please restart the servers and try again?

 

Also try the replication using the command line (cm replicate) with the "--stack" parameter and send to me the full error.

 

Which type of connection are you using? The SSL or the regular one?

Link to comment
Share on other sites

  • 3 years later...
  • 2 months later...

Fixed!!!!!!!!!!!!!!!!!!!!!!!!

 

Integrated in: 5.4.16.747

 

 

 

[bug] Very rarely the Sync View failed with a "Binary Stream '0'" error. If you were unlucky enough to see one of these, don't worry, you are safe now.
It was a very rare bug, hard to reproduce, that almost nobody suffered. It has been fixed thanks to Unai Landa from Digital Legends ;-).
The wild and crazy bug has been around for about 7 years and it was a problem in the network layer. The server zips every response sent back to the client. When the compression didn't succeed (very rare) the client was eating some header bytes incorrectly, expecting compression to happen. Then the error showed up.
Fortunately, it has been caught and jailed.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...