2.13.4 indexes are not persistent?

259 views
Skip to first unread message

Jacek Centkowski

unread,
Dec 22, 2016, 12:53:28 PM12/22/16
to Repo and Gerrit Discussion
Thesis: clean install of Gerrit 2.13.4 (upgrade behaves the same) can't persist indexes (I have focused mostly on changes, but accounts seems to behave the same :/)

Steps to reproduce:
1. build and install gerrit
cd gerrit
git checkout v2.13.4
git submodule init
git submodule sync
git submodule update

buck clean && rm -rf ~/.gerritcodereview/buck-cache/locally-built-artifacts buck-out/gen && buck build release

../../apps/gerrit/bin/gerrit.sh stop || true #just in case something was running

rm -rf ../../apps/gerrit #wipe out whatever was there

mkdir -p ../../apps/gerrit/etc

#general purpose config preparation
git config --file ../../apps/gerrit/etc/gerrit.config gerrit.basePath git
git config --file ../../apps/gerrit/etc/gerrit.config gerrit.canonicalWebUrl http://localhost:8081/
git config --file ../../apps/gerrit/etc/gerrit.config database.type h2
git config --file ../../apps/gerrit/etc/gerrit.config auth.type DEVELOPMENT_BECOME_ANY_ACCOUNT
git config --file ../../apps/gerrit/etc/gerrit.config container.user $(whoami)
git config --file ../../apps/gerrit/etc/gerrit.config container.javaOptions "-Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=6666,suspend=n"
git config --file ../../apps/gerrit/etc/gerrit.config sshd.listenAddress "*:29418"
git config --file ../../apps/gerrit/etc/gerrit.config sshd.backend NIO2
git config --file ../../apps/gerrit/etc/gerrit.config httpd.listenUrl "http://*:8081/"
git config --file ../../apps/gerrit/etc/gerrit.config plugins.allowRemoteAdmin true

#init site and start
java -jar buck-out/gen/release/release.war init -d ../../apps/gerrit --batch
../../apps/gerrit/bin/gerrit.sh start

index directory:

ls -al ../../apps/gerrit/index/changes_0032/open

total 8

drwxr-xr-x  4 jcentkowski  staff  136 Dec 22 17:48 .

drwxr-xr-x  4 jcentkowski  staff  136 Dec 22 17:43 ..

-rw-r--r--  1 jcentkowski  staff   71 Dec 22 17:48 segments_1

-rw-r--r--  1 jcentkowski  staff    0 Dec 22 17:43 write.lock


2. create project with empty commit
3. create review, publish and comment on it, index directory looks like:

ls -al ../../apps/gerrit/index/changes_0032/open

total 40

drwxr-xr-x  7 jcentkowski  staff   238 Dec 22 18:37 .

drwxr-xr-x  4 jcentkowski  staff   136 Dec 22 17:43 ..

-rw-r--r--  1 jcentkowski  staff   363 Dec 22 18:37 _2.cfe

-rw-r--r--  1 jcentkowski  staff  6488 Dec 22 18:37 _2.cfs

-rw-r--r--  1 jcentkowski  staff   361 Dec 22 18:37 _2.si

-rw-r--r--  1 jcentkowski  staff    71 Dec 22 17:48 segments_1

-rw-r--r--  1 jcentkowski  staff     0 Dec 22 17:43 write.lock


4. stop gerrit
../../apps/gerrit/bin/gerrit.sh stop

index directory looks still fine:

ls -al ../../apps/gerrit/index/changes_0032/open

total 40

drwxr-xr-x  7 jcentkowski  staff   238 Dec 22 18:37 .

drwxr-xr-x  4 jcentkowski  staff   136 Dec 22 17:43 ..

-rw-r--r--  1 jcentkowski  staff   363 Dec 22 18:37 _2.cfe

-rw-r--r--  1 jcentkowski  staff  6488 Dec 22 18:37 _2.cfs

-rw-r--r--  1 jcentkowski  staff   361 Dec 22 18:37 _2.si

-rw-r--r--  1 jcentkowski  staff    71 Dec 22 17:48 segments_1

-rw-r--r--  1 jcentkowski  staff     0 Dec 22 17:43 write.lock


5. start gerrit:

$ ../../apps/gerrit/bin/gerrit.sh start

Starting Gerrit Code Review: OK

                                                                                                                                                                                                                                                                                  

ls -al ../../apps/gerrit/index/changes_0032/open

total 8

drwxr-xr-x  4 jcentkowski  staff  136 Dec 22 18:38 .

drwxr-xr-x  4 jcentkowski  staff  136 Dec 22 17:43 ..

-rw-r--r--  1 jcentkowski  staff   71 Dec 22 17:48 segments_1

-rw-r--r--  1 jcentkowski  staff    0 Dec 22 17:43 write.lock


at this moment it looks already bad :/ when one logins to gerrit open reviews list is empty :/

Running online reindex helps until next Gerrit restart. When one upgrades (from for instance 2.13.2) whatever was the content prior upgrade stays. Running offline reindex persists current state but whatever is added later goes away after restart :/

Can anyone confirm it?
Thanks
Jacek

Luca Milanesio

unread,
Dec 22, 2016, 1:02:15 PM12/22/16
to Jacek Centkowski, Repo and Gerrit Discussion
Indexes are persisted every 5 minutes (by default).

It is configurable though:

HTH

Luca.

-- 
-- 
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.

Jacek Centkowski

unread,
Dec 22, 2016, 1:46:17 PM12/22/16
to Repo and Gerrit Discussion, geminica...@gmail.com
I should have known if sth is configurable it will be configurable for sure in gerrit.config :)
Thanks for pointing out to corresponding configuration. Works as designed no issues there.

Regards
Jacek

Luca Milanesio

unread,
Dec 22, 2016, 5:15:55 PM12/22/16
to Jacek Centkowski, Repo and Gerrit Discussion
There is one problem though: how did you stop Gerrit? Gracefully or not?
If you stop gracefully, IMHO Gerrit should trigger a Index flush and wait for Lucene to commit its data before stopping the VM.

Luca.

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

Jacek Centkowski

unread,
Dec 23, 2016, 12:16:23 AM12/23/16
to Luca Milanesio, Repo and Gerrit Discussion
Would say that one can't stop more gracefully than that: 
../../apps/gerrit/bin/gerrit.sh stop

And this is how I did. There's also another thing that bothers me (also reason why I was fooled :)): what's the point of kind of a storing (I was examining index with Luke after stop and new entries were officially not there but size remains the same if one waits long enough to have it persisted) data to file immediately (see the directory content after stop) and wait Xmin so that they got removed if one decides to stop Gerrit in the meantime... It could be implementation specific though...

Regards 
Jacek

luca.mi...@gmail.com

unread,
Dec 23, 2016, 2:03:39 AM12/23/16
to Jacek Centkowski, Repo and Gerrit Discussion
It is definitely a bug then, or a missing part of the implementation :-)

Should the stop command be changed into an API instead of signal handler? There should be a "exit when you're done" that put Gerrit in "read only preparing for shutdown" and then finishing up all the pending stuff:
- replication queue
- other commands in queue
- index flush 
- other?

Luca

Sent from my iPhone

thomasmu...@yahoo.com

unread,
Dec 23, 2016, 9:08:48 AM12/23/16
to Repo and Gerrit Discussion
Oh just saw this thread, i belive i am having the same problem too. https://groups.google.com/forum/#!topic/repo-discuss/bUmnCnQ9A20 may be related.

Remy Bohmer

unread,
Dec 27, 2016, 2:02:54 PM12/27/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion
Hi,

I can confirm that this is a regression in 2.13 somewhere since
2.11.10. 2.11.10 does not have this issue.
Our automated testing trips on this issue in 2.13.4 while it worked
fine on 2.11.10.

Kind regards,

Remy


2016-12-23 15:08 GMT+01:00 thomasmulhall410 via Repo and Gerrit
Discussion <repo-d...@googlegroups.com>:

Remy Bohmer

unread,
Dec 27, 2016, 2:30:49 PM12/27/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion
Hi,

Setting this setting:
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#index.name.commitWithin
to '0' does not prevent or solve the issue, as such this is not a
workaround :-(

Kind regards,

Remy

Remy Bohmer

unread,
Dec 27, 2016, 3:02:41 PM12/27/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion, Luca Milanesio, Jacek Centkowski
Hi,

Some more info, these are the steps:
* We initialized the site with 2.13.4 with a full offline reindex
after upgrading from 2.11.10. Of course with full init procedure and
database scheme upgrades.
* Startup the Gerrit server regularly.
* Then upload 30 changes for one project.
* Restart the server cleanly through bin/gerrit.sh restart
* All 30 changes are gone in the UI. This is the case with setting
'commitWithin' to 0 or this setting left unset to get the default
timeout of 5 minutes.

* While running the reindex through the REST-API at
/a/changes/${change}/index, the respond is 'not found' --> The change
does not reappear in the UI, so this type of reindex fails as well.

Looking into Git and MySQL: The changes are in both the GIT-repo and
the MySQL database. (changes table).

This Groovy script to trigger online reindex does not work for 2.13:
https://gerrit.googlesource.com/plugins/scripts/+/refs/heads/master/admin/reindexer-1.0.groovy,
as such not tested if that could be a workaround.

Kind regards,

Remy

thomasmu...@yahoo.com

unread,
Dec 28, 2016, 1:21:01 PM12/28/16
to Repo and Gerrit Discussion
There should be a gerrit stop command that will put gerrit kind of into read only mode so that no one can upload changes, then gerrit should index the changes then it should stop. Same should be applied to the restart command. There should be a force-stop and force-restart command to force a restart or stop.


On Thursday, December 22, 2016 at 5:53:28 PM UTC, Jacek Centkowski wrote:

Remy Bohmer

unread,
Dec 28, 2016, 3:15:12 PM12/28/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion, Luca Milanesio, Jacek Centkowski
Hi,

One update regarding this comment:
> This Groovy script to trigger online reindex does not work for 2.13:
> https://gerrit.googlesource.com/plugins/scripts/+/refs/heads/master/admin/reindexer-1.0.groovy,

We noticed this is not needed anymore.
We now have: ssh -p 29418 localhost gerrit index start changes --force

This triggers the online reindex, and that brings back the lost
changes, but take many hours to complete.

Kind regards,

Remy

Remy Bohmer

unread,
Dec 29, 2016, 11:22:31 AM12/29/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion, Luca Milanesio, Jacek Centkowski, hugo...@ericsson.com
Hi All,

The revert below is the first bad commit that causes the issue.

Kind regards,

Remy

2e382534c0b96d48e9ec6a257bb692c332e1d302 is the first bad commit
commit 2e382534c0b96d48e9ec6a257bb692c332e1d302
Author: Hugo Arès <hugo...@ericsson.com>
Date: Thu Sep 22 17:43:15 2016 +0200

Revert "Drain executor of index change requests before closing index"

This reverts commit 804f1d9c19d600e5cd94fd554360421d415b5f4a.

The intention was to drain and close the executor before closing the
index but closing an index doesn't necessarily means that executor
should be closed. After online reindexing is completed, the old index
version is closed which closed the executor and make any subsequent
Lucene interaction fails.

Bug: Issue 4618
Change-Id: I6ec90eb73312008714aa790308e806a0134a124e

:040000 040000 946c061c8235ab034e3b1bc91f0e0e3aed53c67e
e00f0db44011d0940b6fa7719605a78235dadca4 M gerrit-lucene

Remy Bohmer

unread,
Dec 29, 2016, 11:31:14 AM12/29/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion, Luca Milanesio, Jacek Centkowski, hugo...@ericsson.com
Hi,

Tested it again by reverting this revert on top of 2.13.4 and that
makes it work properly again on this aspect.
So, the bug-fix for issue 4618 has a side-effect that the index is not
properly closed on shutdown/restart of Gerrit.

Kind regards,

Remy

Luca Milanesio

unread,
Dec 29, 2016, 11:37:42 AM12/29/16
to Remy Bohmer, thomasmu...@yahoo.com, Repo and Gerrit Discussion, Jacek Centkowski, Hugo Arès, Jonathan Nieder
Look at the comments of that change: it seems that it was "very well know" as side-effect of this fix.

Jonathan said:
"

This would presumably reintroduce the bug fixed by the reverted change.

After this revert, does hitting ctrl+c leave changes unindexed again?

"

Worth asking then Jonathan and Hugo on their point of view?

:-)

Luca.

David Ostrovsky

unread,
Dec 29, 2016, 2:46:51 PM12/29/16
to Repo and Gerrit Discussion

Am Donnerstag, 29. Dezember 2016 17:37:42 UTC+1 schrieb lucamilanesio:
Look at the comments of that change: it seems that it was "very well know" as side-effect of this fix.

Jonathan said:
"

This would presumably reintroduce the bug fixed by the reverted change.

After this revert, does hitting ctrl+c leave changes unindexed again?

"

Worth asking then Jonathan and Hugo on their point of view?

Jonathan's fix broke online reindexing and that why it was reverted.
So, atm. we can only choose between breaking online reindexing
or breaking clean shutdown. We went for fixing online reindexing.
But, obviously, we should fix clean shutdown ASAP.

Remy Bohmer

unread,
Dec 29, 2016, 6:41:03 PM12/29/16
to David Ostrovsky, Repo and Gerrit Discussion
Hi,

Op 29 dec. 2016 20:46 schreef "David Ostrovsky" <david.o...@gmail.com>:

For what it is worth: it is choosing between 2 evil's, but we could live with a non functional online reindex but not with a disfunctional restart. In that case Gerrit can be up as long as required. Then a 10 second restart can be done anytime without needing to do a off or online reindex that keeps Gerrit in an inconsistent state for many hours.

Please note that the issue is hard reproducible: _every_ 'bin/gerrit.sh restart' results in a corrupt index now. It is not dependent on the number of threads configured for indexing, and immediate flushes to disk on write does not work either. There is no workaround known to us.

Please let us know how we can help finding a decent solution quickly.

Thanks and Kind regards,

Remy

Luca Milanesio

unread,
Dec 29, 2016, 6:45:12 PM12/29/16
to Remy Bohmer, David Ostrovsky, Repo and Gerrit Discussion
Let's put in this way, they are both evils and both lead to an inconsistent index.

1. On-line reindex: the first restart after an upgrade will make the index inconsistent 
2. Restart: every time you restart, your index is inconsistent

so ...

1. hurts once every 3 months
2. hurts *every time*

I would say ... let's go for fixing 2. (restart) and then work hard to fix 1. without breaking 2. again :-)

P.S. How do the guys @Ericsson manage restarts? Do they trigger an on-line reindex after every restart? It would take hours and overload their CPU :-O

Luca.

Remy Bohmer

unread,
Dec 30, 2016, 5:39:31 AM12/30/16
to Luca Milanesio, Repo and Gerrit Discussion, David Ostrovsky
Hi,

Op 30 dec. 2016 00:45 schreef "Luca Milanesio" <luca.mi...@gmail.com>:

Let's put in this way, they are both evils and both lead to an inconsistent index.

1. On-line reindex: the first restart after an upgrade will make the index inconsistent 
2. Restart: every time you restart, your index is inconsistent

so ...

1. hurts once every 3 months
2. hurts *every time*

And... 1 has a workaround in the sense of offline reindex, but 2 does not have a workaround at all.


I would say ... let's go for fixing 2. (restart) and then work hard to fix 1. without breaking 2. again :-)

I could not agree more :-)

Kind regards,

Remy

Luca Milanesio

unread,
Dec 30, 2016, 5:46:19 AM12/30/16
to Remy Bohmer, Repo and Gerrit Discussion, David Ostrovsky
On 30 Dec 2016, at 10:39, Remy Bohmer <li...@bohmer.net> wrote:

Hi,

Op 30 dec. 2016 00:45 schreef "Luca Milanesio" <luca.mi...@gmail.com>:
Let's put in this way, they are both evils and both lead to an inconsistent index.

1. On-line reindex: the first restart after an upgrade will make the index inconsistent 
2. Restart: every time you restart, your index is inconsistent

so ...

1. hurts once every 3 months
2. hurts *every time*

And... 1 has a workaround in the sense of offline reindex, but 2 does not have a workaround at all.

You need to put into Hugo's shoes ... off-line reindexing would take *days* for them, so it wasn't a workaround for them at all.
But I would agree that for the rest of the Community, it is a "good enough" workaround for a once-in-a-3-months problem.

Remy Bohmer

unread,
Dec 30, 2016, 6:00:12 AM12/30/16
to Luca Milanesio, Repo and Gerrit Discussion, David Ostrovsky
Hi,

Op 30 dec. 2016 11:46 schreef "Luca Milanesio" <luca.mi...@gmail.com>:


On 30 Dec 2016, at 10:39, Remy Bohmer <li...@bohmer.net> wrote:

Hi,

Op 30 dec. 2016 00:45 schreef "Luca Milanesio" <luca.mi...@gmail.com>:
Let's put in this way, they are both evils and both lead to an inconsistent index.

1. On-line reindex: the first restart after an upgrade will make the index inconsistent 
2. Restart: every time you restart, your index is inconsistent

so ...

1. hurts once every 3 months
2. hurts *every time*

And... 1 has a workaround in the sense of offline reindex, but 2 does not have a workaround at all.

You need to put into Hugo's shoes ... off-line reindexing would take *days* for them, so it wasn't a workaround for them at all.

Indeed, the validity of this workaround depends on the time the actual reindex takes. In our case 4 hours for about 200,000 changes, annoying but we can live with it, up to days of unusable system... In that case I would not consider it a workaround either.

Let's fix the issue :-)

Kind regards,

Remy

But I would agree that for the rest of the Community, it is a "good enough" workaround for a once-in-a-3-months problem.



I would say ... let's go for fixing 2. (restart) and then work hard to fix 1. without breaking 2. again :-)

I could not agree more :-)

Kind regards,

Remy


--
--
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.

Luca Milanesio

unread,
Dec 30, 2016, 6:10:54 AM12/30/16
to Remy Bohmer, Repo and Gerrit Discussion, David Ostrovsky
Although shipping a version of Gerrit without on-line reindexing .... ehm ... it's a showstopper :-(
Both issues need to be fixed: why not accepting "a bit" of copy&paste in that code?

At the moment the close() is used during shutdown and at the end of on-line reindexing: let's split into two methods as a quick-fix?

Luca.

Sven Selberg

unread,
Dec 30, 2016, 6:29:54 AM12/30/16
to Repo and Gerrit Discussion, li...@bohmer.net, david.o...@gmail.com


At the moment the close() is used during shutdown and at the end of on-line reindexing: let's split into two methods as a quick-fix?

Luca.

Isn't it a fact that if we could fix it in two methods we could fix it in one?
The problem seems to be that both index versions share the same ExecutorService, so when the ExecutorService is purged and killed there's a big problem.
What if we let each index version have it's own ExecutorService? Would that be a bad thing?
Off course we would have one extra while the online reindexing is cathing up, but eventually we would have only one.

/Sven 

Luca Milanesio

unread,
Dec 30, 2016, 6:32:24 AM12/30/16
to Sven Selberg, Repo and Gerrit Discussion, li...@bohmer.net, David Ostrovsky
That was my intention: splitting the two contexts and close them independently.

That is:
- when you finish up on-line reindexing => close that reindex context
- when you finish up with Gerrit => close the index context

Luca.

--
--
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.

Sven Selberg

unread,
Dec 30, 2016, 6:44:46 AM12/30/16
to Repo and Gerrit Discussion, sven.s...@axis.com, li...@bohmer.net, david.o...@gmail.com
I might have misread the code and what I'm saying doesn't make sense but...

If they don't share the same ExecutorService you don't have to worry about the context, we have already separated the shared context.
If .close() is called on a LuceneChangeIndex for a specific version X, then it's executor is purged and killed, not affecting the LuceneChangeIndex for version X+1 since it has it's own executor.
If gerrit is killed then close() is called for both LuceneChangeIndexes, and both of their executors are purged and killed.

Perhaps that was what you meant by context :-)

/Sven

Luca Milanesio

unread,
Dec 30, 2016, 6:47:25 AM12/30/16
to Sven Selberg, Repo and Gerrit Discussion, li...@bohmer.net, David Ostrovsky
On 30 Dec 2016, at 11:44, Sven Selberg <sven.s...@axis.com> wrote:

I might have misread the code and what I'm saying doesn't make sense but...

Possibly :-) Let re-read the code ...

Luca Milanesio

unread,
Dec 30, 2016, 6:50:31 AM12/30/16
to Sven Selberg, Repo and Gerrit Discussion, li...@bohmer.net, David Ostrovsky
On 30 Dec 2016, at 11:44, Sven Selberg <sven.s...@axis.com> wrote:

I might have misread the code and what I'm saying doesn't make sense but...

If they don't share the same ExecutorService you don't have to worry about the context, we have already separated the shared context.

I see the injected executor: so we should have just different executors and we can keep the same method, yes.

lucamilanesio

unread,
Dec 30, 2016, 9:05:20 AM12/30/16
to Repo and Gerrit Discussion, sven.s...@axis.com, li...@bohmer.net, david.o...@gmail.com
Actually things are more complex: the on-line reindexer needs to use the same INTERACTIVE executor for the index, because when the new index is ready will be swapped with the current one.

I believe they just need to be different methods, one that just queue the closing of the index on the current executor and the other that is actually a close and drain.
They both need to share the same executor as they are both interactive indexes.

Luca.

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.

Sven Selberg

unread,
Dec 30, 2016, 9:47:38 AM12/30/16
to Repo and Gerrit Discussion, sven.s...@axis.com, li...@bohmer.net, david.o...@gmail.com
Didn't manage to follow the guice breadcrumbs that far...see my comment about me misreading the code :-)

Happy new year!

/Sven

lucamilanesio

unread,
Dec 30, 2016, 10:05:45 AM12/30/16
to Repo and Gerrit Discussion, sven.s...@axis.com, li...@bohmer.net, david.o...@gmail.com
There you go:

This fixes BOTH problem 1. and 2. because separates the drainage of indexing threads (shutdown case) from the actual index close (on-line reindex).

I tested it by upgrading a Gerrit 2.12 to a 2.13 and:
- on-line reindexing worked like a charm
- shutdown / restart (gracefully with kill -1) flushed all the pending indexing to disk

Hope Hugo and Jonathan will aprove it :-)

Happy New Year !

Luca.

thomasmu...@yahoo.com

unread,
Dec 30, 2016, 10:19:46 AM12/30/16
to Repo and Gerrit Discussion
@Luca thankyou very much for fixing it and also managing to get both online reindex and clean shutdown both to work without breaking them. :)

Luca Milanesio

unread,
Dec 30, 2016, 10:22:58 AM12/30/16
to thomasmu...@yahoo.com, Repo and Gerrit Discussion
Actually the one for stable-2.13 is:

I pushed the previous one on master, which was obviously failing :-(

Remy Bohmer

unread,
Dec 30, 2016, 10:33:47 AM12/30/16
to Luca Milanesio, Repo and Gerrit Discussion, thomasmu...@yahoo.com
Hi Luca,

Very nice! Patch looks good to me 😀.
I will validate it as well tomorrow morning.

Happy New Year!

Remy


Op 30 dec. 2016 4:22 p.m. schreef "Luca Milanesio" <luca.mi...@gmail.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.

For more options, visit https://groups.google.com/d/optout.

--
--
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.

Luca Milanesio

unread,
Dec 30, 2016, 10:51:13 AM12/30/16
to Remy Bohmer, Repo and Gerrit Discussion, thomasmu...@yahoo.com
And it's Verified on CI as well :-)

GerritForge CI posted comments on this change.

View Change

Patch Set 1: Verified+1

Gerrit-CI Build: https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-change/5050/console

thomasmu...@yahoo.com

unread,
Dec 30, 2016, 11:25:23 AM12/30/16
to Repo and Gerrit Discussion
Tested and works :)

Sven Selberg

unread,
Jan 2, 2017, 5:12:38 AM1/2/17
to Repo and Gerrit Discussion, thomasmu...@yahoo.com

Great work Luca, Thanks!

Sven Selberg



---- thomasmulhall410 via Repo and Gerrit Discussion skrev ----

--
--
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.

Hugo Arès

unread,
Jan 3, 2017, 7:30:31 AM1/3/17
to Repo and Gerrit Discussion, li...@bohmer.net, thomasmu...@yahoo.com
Sorry for not joining discussion before, I was totally disconnected during vacation.

Thanks for investigating and fixing both issues. I am glad we will not need to do offline reindexing, going offline for 28h-30h is not an option for us. Somehow, we are not loosing changes when we restart, but maybe our 2 masters, each having a copy of the index, is shielding us from that issue.

Hugo
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.


--
--
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.
Reply all
Reply to author
Forward
0 new messages