Is this a Bug in Gerrit version 2.14.4

[devops]

All our changes are showing as merge conflict in Gerrit version 2.14.4

we have upgraded from 2.11.7 to 2.14.4

any idea whats causing this ? Is this a bug ?

[David Pursehouse]

Has reindexing completed?

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[devops]

Yes, reindexing has been done

[devops]

Any idea whats causing this ?

[devops]

One thing is interesting to note is, all the changes are showing merge conflict in old UI, but not in new UI

[devops]

Is this expected in gerrit version 2.14.4

there is db folder created upgrade in 2.14.4 having below content

[root@xxxxxxx db]# ls -ltr

total 34004

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

[David Ostrovsky]

Am Dienstag, 26. September 2017 13:56:35 UTC+2 schrieb devops:

Is this expected in gerrit version 2.14.4

there is db folder created upgrade in 2.14.4 having below content

[root@xxxxxxx db]# ls -ltr

total 34004

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

Have you read the account_patch_reviews related question in this thread: [1] and my answer?

[1] https://groups.google.com/d/topic/repo-discuss/Scj0IWrP8wg/discussion

[devops]

Is that applicable for me too ??

Below is my database details

[database]

        type = ORACLE

        database = db/ReviewDB

        instance = xxxx

        username = xxx

        port = 1521

        hostname = xxxx

        connectionpool = true

        poolmaxidle = 16

        poolLimit = 160

        poolMaxWait = 2min

        dataSourceInterceptorClass = com.googlesource.gerrit.plugins.javamelody.MonitoringDataSourceInterceptor

[gc]

        interval = 1 week

        startTime = Thu 11:00

[David Ostrovsky]

Am Dienstag, 26. September 2017 14:07:36 UTC+2 schrieb devops:

Is that applicable for me too ??

You show us how your ReviewDb is configured. My answer was:

"This table is not a part of ReviewDb database. Per default, it's standalone H2

database."

You show us H2-database, that confirmed what I was saying:

[devops]

We are using ReviewDb and on upgrade we are getting 

[root@xxxxxxx db]# ls -ltr

total 34004

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

So Is this expected ?

[Edwin Kempin]

On Tue, Sep 26, 2017 at 2:41 PM, devops <sakshiso...@gmail.com> wrote:

We are using ReviewDb and on upgrade we are getting 

[root@xxxxxxx db]# ls -ltr

total 34004

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

So Is this expected ?

Yes. As David explained account patch reviews are now stored in H2 outside of ReviewDb.

 

On Tuesday, September 26, 2017 at 6:09:06 PM UTC+5:30, David Ostrovsky wrote:

Am Dienstag, 26. September 2017 14:07:36 UTC+2 schrieb devops:

Is that applicable for me too ??

You show us how your ReviewDb is configured. My answer was:

"This table is not a part of ReviewDb database. Per default, it's standalone H2

database."

You show us H2-database, that confirmed what I was saying:

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[devops]

Could you please point me to the documentation where it is written ?

[Edwin Kempin]

On Tue, Sep 26, 2017 at 3:03 PM, devops <sakshiso...@gmail.com> wrote:

Could you please point me to the documentation where it is written ?

David already provided the links to the documentation:

  https://groups.google.com/d/msg/repo-discuss/Scj0IWrP8wg/d8Dyt3I0AAAJ

You can also implement a plugin to store this data in another place:

https://gerrit-review.googlesource.com/Documentation/dev-plugins.html#account-patch-review-store

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[devops]

Do you know why its not the part of "Important notes" here https://www.gerritcodereview.com/releases/2.14.md ?

I am not sure if I know what needs to be done in my case.

I am upgrading from 2.11.7 to 2.14.4 directly

On Tuesday, September 26, 2017 at 6:40:01 PM UTC+5:30, Edwin Kempin wrote:

On Tue, Sep 26, 2017 at 3:03 PM, devops <sakshiso...@gmail.com> wrote:

Could you please point me to the documentation where it is written ?

David already provided the links to the documentation:

  https://groups.google.com/d/msg/repo-discuss/Scj0IWrP8wg/d8Dyt3I0AAAJ

You can also implement a plugin to store this data in another place:

https://gerrit-review.googlesource.com/Documentation/dev-plugins.html#account-patch-review-store

 

On Tuesday, September 26, 2017 at 6:11:17 PM UTC+5:30, devops wrote:

We are using ReviewDb and on upgrade we are getting 

[root@xxxxxxx db]# ls -ltr

total 34004

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

So Is this expected ?

On Tuesday, September 26, 2017 at 6:09:06 PM UTC+5:30, David Ostrovsky wrote:

Am Dienstag, 26. September 2017 14:07:36 UTC+2 schrieb devops:

Is that applicable for me too ??

You show us how your ReviewDb is configured. My answer was:

"This table is not a part of ReviewDb database. Per default, it's standalone H2

database."

You show us H2-database, that confirmed what I was saying:

-rw-r--r-- 1 gerrit gerrit 34813952 Sep 26 10:16 account_patch_reviews.h2.db

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[devops]

Are you talking about this here

Updated primary key on JdbcAccountPatchReviewStore

In version 2.14.4 the fields in the JdbcAccountPatchReviewStore primary key are reordered to improve performance when clearing the reviewed flag for a patch set.

Sites that have already upgraded from an earlier version to 2.13, or to a 2.14.x version before 2.14.4, and want to take advantage of this performance improvement, should manually drop and recreate the primary key as follows:

  # drop the key
  ALTER TABLE account_patch_reviews
  DROP CONSTRAINT primary_key_account_patch_reviews;
  # recreate the key
  ALTER TABLE account_patch_reviews
  ADD CONSTRAINT primary_key_account_patch_reviews
  PRIMARY KEY (change_id, patch_set_id, account_id, file_name);

Note that this is optional. The site will continue to work without this update.

The update is not necessary when upgrading directly to 2.14.4 from a version earlier than 2.13, as the primary key will be created with the updated order anyway.

[Edwin Kempin]

On Tue, Sep 26, 2017 at 3:12 PM, devops <sakshiso...@gmail.com> wrote:

Do you know why its not the part of "Important notes" here https://www.gerritcodereview.com/releases/2.14.md ?

I am not sure if I know what needs to be done in my case.

 

You need to do nothing. The migration of account patch reviewed flags from ReviewDb to H2 is automatic.

And since account_patch_reviews.h2.db was created for you it seems that this migration worked.

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[devops]

Thanks Edwin for clearing the confusion.

Thanks a lot 

But, I have tried to upgrade twice and still all my changes are showing as "Merge Conflict"

Do you have any idea why ?

[Luca Milanesio]

Do you have any plugins that are influencing the permissions or rules evaluation?

(owners, singleusergroup, github, oauth, ...)

Luca.

[Edwin Kempin]

On Tue, Sep 26, 2017 at 3:29 PM, devops <sakshiso...@gmail.com> wrote:

Thanks Edwin for clearing the confusion.

Thanks a lot 

But, I have tried to upgrade twice and still all my changes are showing as "Merge Conflict"

Do you have any idea why ?

No, but it's for sure unrelated to account patch reviewed flags.

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[devops]

Here is the plugin we have

bash-4.1$ cd plugins/

bash-4.1$ ls -ltr

total 376

-rw-r--r-- 1 gerrit gerrit  10714 Jul  7 13:00 javamelody.jar

-rw-r--r-- 1 gerrit gerrit  46099 Jul  8 12:25 delete-project.jar

-rw------- 1 gerrit gerrit   5107 Sep 26 12:53 commit-message-length-validator.jar

-rw------- 1 gerrit gerrit  41494 Sep 26 12:53 hooks.jar

-rw------- 1 gerrit gerrit  24336 Sep 26 12:53 download-commands.jar

-rw------- 1 gerrit gerrit  22682 Sep 26 12:53 reviewnotes.jar

-rw------- 1 gerrit gerrit 210629 Sep 26 12:53 replication.jar

-rw------- 1 gerrit gerrit   8046 Sep 26 12:53 singleusergroup.jar

Luca.

To unsubscribe, email repo-disc...@googlegroups.com

[Luca Milanesio]

It's the singleusergroup that creates this situation.

There was a bug in the way the reindexing was triggered and the plugins weren't loaded in the right order: that generated errors in the evaluation of the change status.

I've fixed the problem in 2.14.2 (see https://bugs.chromium.org/p/gerrit/issues/detail?id=6472) so, in theory, you should have had the fix.

Did you perform on-line or off-line reindex?

When you do off-line reindex *and* you have plugins that influence the project rules and/or ACL evaluation, the off-line reindex may not recalculate the change status correctly.

Luca.

[devops]

I am upgrading from 2.11.7 to 2.14.4 directly.

I should have had the fix already.

I performed offline reindexing

When you do off-line reindex *and* you have plugins that influence the project rules and/or ACL evaluation, the off-line reindex may not recalculate the change status correctly.

So it didn't calculate status correctly, right and its a bug again?

To unsubscribe, email repo-disc...@googlegroups.com

[Luca Milanesio]

On 26 Sep 2017, at 14:52, devops <sakshiso...@gmail.com> wrote:

I am upgrading from 2.11.7 to 2.14.4 directly.

I should have had the fix already.

I performed offline reindexing

When you do off-line reindex *and* you have plugins that influence the project rules and/or ACL evaluation, the off-line reindex may not recalculate the change status correctly.

So it didn't calculate status correctly, right and its a bug again?

So, it depends on the point of view :-)

A bug is a mismatch between an expected behaviour and the implementation. In this case, it is not.

The off-line reindex *isn't* loading any plugin and thus is by design not compatible with any reindex where the plugin are influencing the status of a change.

Example scenario: Change A can be submitted by user U because of an ACL using a group "user/U"

Change A can be reindexed correctly ONLY if the plugin resolving "user/U" is loaded. Thus off-line reindex is not suitable in this case.

Remember that reindex is not only updating the Lucene entry but is recalculating the full change status.

Hope this clarify.

Luca.

[devops]

Could you please let me know how to resolve this issue ?

I do not have clear instructions how to resolve it

To unsubscribe, email repo-disc...@googlegroups.com

[Luca Milanesio]

You need to repeat the migration using on-line reindex for the changes.

As you're skipping versions, you would need to go through 2.12 and 2.13 first.

Luca.

[devops]

To use online reindexing for the changes secondary index when upgrading to 2.13.x, the server must first be upgraded to 2.8 (or 2.9) and then through 2.10, 2.11 and 2.12. Skipping a version will prevent the online reindexer from working.

we didnt upgrade to 2.9, 2.10 earlier, i.e we skipped it earlier too , so I have to go back to 2.10, 2.9 from 2.11.7 and do the upgrades again ? Since skipping a version will prevent the online reindexer from working. ???

Luca.

To unsubscribe, email repo-disc...@googlegroups.com

[devops]

In Past, we upgraded from 2.9.1 to 2.11.7 directly.

So now if I upgrade from 2.11.7 to 2.12 to 2.13, then also online reindex will not be available since we skipped versions in the past

[Luca Milanesio]

Right, the only option is then to do off-line reindexing and *then* reindex all the changes on-line again, using the SSH or REST API.

Luca.

[devops]

Right, the only option is then to do off-line reindexing and *then* reindex all the changes on-line again, using the SSH or REST API.

Does the above statement means, I should first downgrade to 2.9, and the upgrade to  2.10, 2.11, 2.12 ,2.13 and then check ?

Or does that mean, I  should reindex all the changes on-line again, using the SSH or REST API without doing any downgrade ??

Luca.

To unsubscribe, email repo-disc...@googlegroups.com

[thomasmu...@yahoo.com]

Hi, he is telling you to do an offline reindex again by doing

java -jar gerrit.war reindex -d review_site --threads 4

replacing .war file name with yours and review_site with your gerrit site path.

then he says do https://gerrit-review.googlesource.com/Documentation/cmd-index-start.html

[devops]

I have tried below steps suggested

bash-4.1$ java -jar gerrit-2.14.4.war reindex

[2017-09-27 12:53:05,809] [main] INFO  com.google.gerrit.server.git.LocalDiskRepositoryManager : Defaulting core.streamFileThreshold to 1784m

[2017-09-27 12:53:06,590] [main] INFO  com.google.gerrit.server.cache.h2.H2CacheFactory : Enabling disk cache /opt/gerrit/cache

Reindexing accounts:    100% (658/658)

Reindexed 658 documents in accounts index in 5.5s (120.5/s)

Reindexing groups:      100% (450/450)

Reindexed 450 documents in groups index in 2.4s (187.3/s)

Collecting projects:    641

Reindexing changes: projects: 100% (641/641), 89% (10224/11402), done

Reindexed 10224 documents in changes index in 57.5s (177.8/s)

and then 

ssh -p 29418 host gerrit index start changes

but NO LUCK :(

Can you please suggest something :(

[devops]

this steps says

bash-4.1$ ssh -p 29418 xxxxxx gerrit index start changes

Nothing to reindex, index is already the latest version

[devops]

Still all my open changes are showing as Merge Conflict 

 
Can any anybody suggest something.I have tried upgrade thrice.

Upgrading from version 2.11.7 to 2.14.4 directly

Is there any issue doing a direct upgrade to 2.14.4 ?

Shall i try incremental upgrades ?

[devops]

to be very clear about the story here 

We did rsync first from prod to QA in order to have same data in QA 

and copied database too from prod to QA

That is Refreshed Gerrit QA with PROD (database & Repositories both)

command ran for rsync on QA

rsync -azv --delete gerrit@prod-host:/opt/gerrit/git/ /opt/gerrit/git/ 

then we verified the data on QA 

and then we followed the upgrade steps 

Do you think this caused any issues ?

[devops]

This is what I see for index in git qa

NEW  version 2.14.4:

bash-4.1$ ls -ltr

total 20

drwxr-xr-x 4 gerrit gerrit 4096 Sep 27 08:49 changes_0014

drwxr-xr-x 4 gerrit gerrit 4096 Sep 27 12:28 changes_0039

drwxr-xr-x 2 gerrit gerrit 4096 Sep 27 12:54 groups_0002

drwxr-xr-x 2 gerrit gerrit 4096 Sep 27 12:54 accounts_0004

-rw-rw-r-- 1 gerrit gerrit  162 Sep 27 12:55 gerrit_index.config

OLD version 2.11.7  :

drwxr-xr-x 4 root root 4096 Sep 27 11:55 changes_0014

-rw-r--r-- 1 root root   27 Sep 27 11:55 gerrit_index.config

[devops]

this is what my index.config has 

[index "14"]

[index "changes_0014"]

        ready = false

[index "accounts_0004"]

        ready = true

[index "groups_0002"]

        ready = true

[index "changes_0039"]

        ready = true

[Hugo Arès]

On Wednesday, September 27, 2017 at 8:57:17 AM UTC-4, devops wrote:

this steps says

bash-4.1$ ssh -p 29418 xxxxxx gerrit index start changes

Nothing to reindex, index is already the latest version

 

you need to pass --force option to force a reindex:

ssh -p 29418 xxxxxx gerrit index start --force changes

[devops]

Hi Hugo,

Thanks, below command worked for me

 ssh -p 29418 host gerrit index start changes --force

I am getting below for special char name repository  i.e datadelivery-feed-tcp-c++. But, i have renamed the repository and deleted it 

Now every time I am running online reindex it is giving same error

[2017-09-28 06:55:48,796] [Index-Batch-2] WARN  com.google.gerrit.server.index.change.StalenessChecker : error checking staleness of 8737 in datadelivery-feed-tcp-c%252B%252B

org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: Invalid name: datadelivery-feed-tcp-c%252B%252B

        at com.google.gerrit.server.git.LocalDiskRepositoryManager.openRepository(LocalDiskRepositoryManager.java:145)

        at com.google.gerrit.server.git.LocalDiskRepositoryManager.openRepository(LocalDiskRepositoryManager.java:139)

        at com.google.gerrit.server.index.change.StalenessChecker.refsAreStale(StalenessChecker.java:195)

        at com.google.gerrit.server.index.change.StalenessChecker.refsAreStale(StalenessChecker.java:128)

        at com.google.gerrit.server.index.change.StalenessChecker.isStale(StalenessChecker.java:116)

        at com.google.gerrit.server.index.change.StalenessChecker.isStale(StalenessChecker.java:99)

        at com.google.gerrit.server.index.change.ChangeIndexer$ReindexIfStaleTask.callImpl(ChangeIndexer.java:441)

        at com.google.gerrit.server.index.change.ChangeIndexer$ReindexIfStaleTask.callImpl(ChangeIndexer.java:434)

        at com.google.gerrit.server.index.change.ChangeIndexer$AbstractIndexTask.call(ChangeIndexer.java:379)

        at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)

        at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)

        at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

        at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:418)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

        at java.lang.Thread.run(Thread.java:745)

[devops]

I have tried flushing cache also

but it is still filling all my logs with below error and its stuck at this error

WARN  com.google.gerrit.server.index.change.StalenessChecker : error checking staleness of 8737 in datadelivery-feed-tcp-c%252B%252B

[海尔优家]

I have the same issue after I rename the repositories and reindex

Have you have resloved this?

在 2017年9月28日星期四 UTC+8下午3:00:52，devops写道：