Jump to content

revInfo Owner is null before the cache


jstarrdewar
 Share

Recommended Posts

I really like the design of PlasticSCM but there are a lot of sharp corners for new users like me!

 

Here's a new one:

 

I created a local repository

 

I replicate/pulled the remote repository (as you can see from the screenshot the history is still very simple)

 

I made a few checkins.

 

I tried to switch the workspace to an earlier changeset. Got an error message along the lines of (failed: Owner is null)

 

Now when I try to switch back to the latest changeset, I get this huge error message. The revInfo.Owner is null before the cache And it refuses to switch to the latest changeset.

 

Worked around it by deleting local repository and redoing the whole setup process but that's a pain.

post-31940-0-45729200-1462226206_thumb.jpg

Link to comment
Share on other sites

  • 1 year later...

Hi,

I am seeing similar symptoms on my home machine.

I needed to pull down an entire new repository from Plastic Cloud to my home machine. Due to unknown reasons I had problems both downloading an updated Plastic Cloud installer. The download failed about 5 times throughout the 160MB download. This could either be my home network - the machine is connected to a home router over a wireless network - or problems with my ISP/Azure. I have not seen similar problems at our office.

Anyhow, after installing a new version of the Plastic SCM client, I created a new sync view and attempted to pull a repository containing perhaps 250-500 branches and ~8GB of data. This failed within minutes. I resorted to doing "cm replicate /main/<child branch>@...@cloud <localrepo>@local" and fetching 1-2 weeks' of work at a time, as otherwise the command-line replication would also fail with messages like "The data for revision 236293 (segment 3) cannot be read from rep 8865.". I also interrupted a few replication operations with Ctrl-C.

At one point, "cm replicate" complained that a changeset was locked. I stopped the local Plastic server and restarted it. The "cm replicate" operation was now capable of performing replications again.

After I had replicated most of the branches, I went into the Plastic SCM GUI and performed a full sync via the sync view. No errors this time.

After this, if I attempt to update the workspace (which previously was empty), after a few seconds I get a popup saying that the Plastic client failed updating certain files on my machine, with the reason "revInfo.Owner is null before the cache". Redoing the operation or forcing the operation does not help.

 

I get messages like these in my server's plastic.debug.log.txt:

2017-11-30 16:44:47,829 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG Transaction - Begin implicit transaction C:\Program Files\PlasticSCM5\server\rep_5.plastic.sqlite
2017-11-30 16:44:47,840 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG BranchExplorerQuery - Read 286 branches 0ms
2017-11-30 16:44:47,871 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG Security - SEID with id 494 was not found
2017-11-30 16:44:47,871 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG Security - SEID with id 494 was not found
2017-11-30 16:44:47,871 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG Security - SEID with id 494 was not found
2017-11-30 16:44:47,871 W-39 00000000-0000-0000-0000-000000000000 kalms@falldamagestudio.com KALMSHOMEDESKTO DEBUG Security - SEID with id 494 was not found

I will make full logs available to you via email tomorrow.

 

This does not block me from working.


Actual questions to you:

- Do you want more material for debugging? like, a snapshot of the SQLite database? (please be specific in which files in that case)

- Is there a sure-fire way to get rid of this problem? other than, say, deleting the local replica and replicating it over again?

 

Link to comment
Share on other sites

Hi!

11 minutes ago, Mikael Kalms said:

Anyhow, after installing a new version of the Plastic SCM client, I created a new sync view and attempted to pull a repository containing perhaps 250-500 branches and ~8GB of data. This failed within minutes

Do you have more info about this first failure?

13 minutes ago, Mikael Kalms said:

I also interrupted a few replication operations with Ctrl-C.

:unsure:

14 minutes ago, Mikael Kalms said:

"The data for revision 236293 (segment 3) cannot be read from rep 8865."

Ugly message.

14 minutes ago, Mikael Kalms said:

After I had replicated most of the branches, I went into the Plastic SCM GUI and performed a full sync via the sync view. No errors this time.

I guess you synchronized the repository where you had the initial failure and then you retry the replica using the command line, right?

15 minutes ago, Mikael Kalms said:

- Do you want more material for debugging? like, a snapshot of the SQLite database? (please be specific in which files in that case)

Yes please, email us the following content to support at codicesoftware dot com:

  • All the "C:\Program Files\PlasticSCM5\server\plastic.debug.log.txt*" you have.
  • Run "cm lrep --format=TABLE" it will give you your repositories, the first column is the repo id. Send us the repo database -> C:\Program Files\PlasticSCM5\server\rep_<ID>.plastic.sqlite
  • Provide us the organization name of the cloud server that was the source of the replication.
22 minutes ago, Mikael Kalms said:

- Is there a sure-fire way to get rid of this problem? other than, say, deleting the local replica and replicating it over again?

We'll need to study it. Can you please retry the replication using a brand new local repository as the destination? I want to test again a clean replication.

Thanks and sorry for the inconveniences.

 

Link to comment
Share on other sites

15 hours ago, manu said:

 

16 hours ago, Mikael Kalms said:

After I had replicated most of the branches, I went into the Plastic SCM GUI and performed a full sync via the sync view. No errors this time.

I guess you synchronized the repository where you had the initial failure and then you retry the replica using the command line, right?

Yes.

I also performed 'cm checkdatabase' -- this confirmed that the DB was not consistent. So I think there are two things, 1) I am having problems pulling and 2) the "cm replicate" command will, under some circumstances, result in inconsistent DB contents. At least when working against .sqlite format DBs. Even despite it using a transaction-based design (right?)

The problems with pulling prevent me from "trying again": I have not yet succeeded in pulling down the repository to that computer in one go.

 

 

I will do tests with a laptop in my home later; it will be connected over the same home Wifi. Will get back to you with info on how well that works.

I have done a full "cm replicate" from the Cloud repo to a local repo on my office workstation now. That replication succeeded without any errors.

Link to comment
Share on other sites

  • 1 month later...

Update on my situation: using Wireshark, I can see that a whole group of TCP packets (50 of them to be precise) are being dropped partway through a blob download from Azure. The random interruptions of "cm replicate" thus look like a problem with my home network.

Apart from that; perhaps aggressive testing of randomly closing TCP connections mid-transfer during write operations to a Plastic repo would help Codice find some corner cases that can result in DB corruptions.

Link to comment
Share on other sites

  • 1 month later...

Hi,

I have sorted out the replication problems I had above (problem with network drivers and packet loss).

 

However, I have a case which you may be interested in following up on for improving reliability in general:

I use Plastic Cloud version 7.0.16.1960. I work against Plastic Cloud, with a local repository on my workstation. I had a consistent local repository on my workstation. Then, I performed a sync replication from Cloud to a local repository via the GUI, choosing "Pull visible". There were ~15 or so branches that were going to be pulled down. Partway through the replication I clicked "Cancel" in the sync replication progress window.

After this, my local repository has been left in an inconsistent state. Attempting to update the workspace via the GUI resulted in "revInfo Owner is null before the cache" messages. Updating the the workspace via the commandline resulted in a number of "The revInfo.Owner is null before the cache" error messages intermingled between file download messages. A "checkdatabase" showed a number of  messages such as "Seid 731 pointed by object 634548 does not exist in database rep_14.plastic.sqlite."

When I checked with the GUI client it appears that I have replicated all the changesets from /main (but not all from a couple of child branches). I still got the errors when I attempt to switch to the newest changeset on /main.

 

It looks to me like the replication operation within Plastic is not properly transaction-safe. Is this the case? If yes, is this something that you intend to improve upon in the future?

 

I will make a backup copy of my sqlite databases; let me know if you need a copy of them for analysis. After this, I will drop my local "rep_14" repository database and re-replicate it from Cloud since this seems to be the only way for me to get back to a good state again.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...