Re: Index documents in async way

[Đạt Cao Mạnh]

> The biggest problem I have with this is that the client doesn't know
about indexing problems without awkward callbacks later to see if something
went wrong.  Even simple stuff like a schema problem (e.g. undefined
field).  It's a useful *option*, any way.
> Currently we now guarantee that if solr sends you an OK response the
document WILL eventually become searchable without further action.
Maintaining that guarantee becomes impossible if we haven't verified that
the data is formatted correctly (i.e. dates are in ISO format, etc).
This may be an acceptable cost for those opting for async indexing but it
may be very hard for some folks to swallow if it became the only option
however.

I don't mean that we're gonna replace the sync way. Plus the way sync
works can be changed to leverage the async method. For example, the sync
thread basically waits until the indexer threads finish indexing that
update. Some notice here is all the validations in update processors will
still happen in *sync* way in this model. Only indexing part to Lucene is
executed in an async way.

> I'm a bit skeptical that would boost indexing performance.  Please
understand the intent of that API is about transactionality (atomic add)
and ensuring all docs go in the same segment.  Solr *does* use that API for
nested / parent-child documents, and because it has to.  If that API were
to get called for normal docs, I could see the configured indexing buffer
RAM or doc limit could be exceeded substantially.  Perhaps not a big deal.
You could test your performance theory on a hacked Solr without much
modifications, I think?  Just buffer then send in bulk.

>
>
> What I mean here is right now, when we send a batch of documents to Solr.
We still process it as concrete - unrelated documents by indexing one by
one. If indexing the fifth document causing error, that won't affect
already indexed 4 documents. Using this model we can index the batch in an
atomic way.

> I think that's the real thrust of your motivations, and sounds good to
me!  Also, please see https://issues.apache.org/jira/browse/SOLR-14778 for
making the optionality of the updateLog be a better supportable option in
SolrCloud.

Thank you for bring it out, I will take a look.

All other parts that did not get quoted are very valuable things and I
really appreciate those.

On Wed, Oct 14, 2020 at 12:06 AM Gus Heck  wrote:

> This is interesting, though it opens a few of cans of worms IMHO.
>
>1. Currently we now guarantee that if solr sends you an OK response
>the document WILL eventually become searchable without further action.
>Maintaining that guarantee becomes impossible if we haven't verified that
>the data is formatted correctly (i.e. dates are in ISO format, etc).
>This may be an acceptable cost for those opting for async indexing but it
>may be very hard for some folks to swallow if it became the only option
>however.
>2. In the case of errors we need to hold the error message
>indefinitely for later discovery by the client, this needs to not
>accumulate forever. Thus:
>   1. We have a timed cleanup, leasing or some other self limiting
>   pattern... possibly by indexing the failures in a TRA with autodelete so
>   that clients can efficiently find the status of the particular 
> document(s)
>   they sent, obviouysly there's at least an asyc id involved, probably the
>   uniqueKey (where available) and timestamps for recieved, and processed 
> as
>   well.
>   2. We log more simply with a sequential id and let clients keep
>   track of what they have seen... This can lead us down the path of
>   re-inventing kafka, or making kafka a required dependency.
>   3. We provide a push oriented connection (websocket? HTTP2?) that
>   clients that care about failures can listen to and store nothing. A less
>   appetizing variant is to publish errors to a message bus.
>3. If we have more than one thread picking up the submitted documents
>and writing them, we need a state machine that identifies in-progress
>documents to prevent multiple pickups and resets processing to new on
>startup to ensure we don't index the same document twice and don't lose
>things that were in-flight on power loss.
>4. Backpressure/throttling. If we're losing ground continuously on the
>submissions because indexing is heavier than accepting documents, we may
>fill up the disk. Of course the index itself can do that, but need to think
>about if this makes it worse.
>
> A big plus to this however is that batches with errors could optionally
> just omit the (one or two?) errored document(s) and publish the error for
> each errored document rather than failing the whole batch, meaning that the
> indexing infrastructure submitting in batches doesn't have to leave several
> hundred docs unprocessed, or alternately do a slow doc at a time resubmit
> to weed out the offenders.
>
> Certainly 

Re: Index documents in async way

[Đạt Cao Mạnh]

> Can there be a situation where the index writer fails after the document
was added to tlog and a success is sent to the user? I think we want to
avoid such a situation, isn't it?
> I suppose failures would be returned to the client one the async response?
To make things more clear, the response for async update will be something
like this
{ "trackId" : "" }
Then the user will call another endpoint for tracking the response like GET
status_updates?trackId=, the response will tell that
whether the update is in_queue, processing, succeed or failed. Currently we
are also adding to tlog first then call writer.addDoc later.
Later we can convert current sync operations by waiting until the update
gets processed before return to users.

>How would one keep the tlog from growing forever if the actual indexing
took a long time?
I think it won't be very different from what we are having now, since on
commit (producer threads do the commit) we rotate to a new tlog.

> I'd like to add another wrinkle to this. Which is to store the
information about each batch as a record in the index. Each batch record
would contain a fingerprint for the batch. This solves lots of problems,
and allows us to confirm the integrity of the batch. It also means that we
can compare indexes by comparing the batch fingerprints rather than
building a fingerprint from the entire index.
Thank you, it adds another pros to this model :P

On Fri, Oct 9, 2020 at 2:10 AM Joel Bernstein  wrote:

> I think this model has a lot of potential.
>
> I'd like to add another wrinkle to this. Which is to store the information
> about each batch as a record in the index. Each batch record would contain
> a fingerprint for the batch. This solves lots of problems, and allows us to
> confirm the integrity of the batch. It also means that we can compare
> indexes by comparing the batch fingerprints rather than building a
> fingerprint from the entire index.
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Thu, Oct 8, 2020 at 11:31 AM Erick Erickson 
> wrote:
>
>> I suppose failures would be returned to the client one the async response?
>>
>> How would one keep the tlog from growing forever if the actual indexing
>> took a long time?
>>
>> I'm guessing that this would be optional..
>>
>> On Thu, Oct 8, 2020, 11:14 Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Can there be a situation where the index writer fails after the document
>>> was added to tlog and a success is sent to the user? I think we want to
>>> avoid such a situation, isn't it?
>>>
>>> On Thu, 8 Oct, 2020, 8:25 pm Cao Mạnh Đạt,  wrote:
>>>
 > Can you explain a little more on how this would impact durability of
 updates?
 Since we persist updates into tlog, I do not think this will be an issue

 > What does a failure look like, and how does that information get
 propagated back to the client app?
 I did not be able to do much research but I think this is gonna be the
 same as the current way of our asyncId. In this case asyncId will be the
 version of an update (in case of distributed queue it will be offset)
 failures update will be put into a time-to-live map so users can query the
 failure, for success we can skip that by leverage the max succeeded version
 so far.

 On Thu, Oct 8, 2020 at 9:31 PM Mike Drob  wrote:

> Interesting idea! Can you explain a little more on how this would
> impact durability of updates? What does a failure look like, and how does
> that information get propagated back to the client app?
>
> Mike
>
> On Thu, Oct 8, 2020 at 9:21 AM Cao Mạnh Đạt  wrote:
>
>> Hi guys,
>>
>> First of all it seems that I used the term async a lot recently :D.
>> Recently I have been thinking a lot about changing the current
>> indexing model of Solr from sync way like currently (user submit an 
>> update
>> request waiting for response). What about changing it to async model, 
>> where
>> nodes will only persist the update into tlog then return immediately much
>> like what tlog is doing now. Then we have a dedicated executor which 
>> reads
>> from tlog to do indexing (producer consumer model with tlog acting like 
>> the
>> queue).
>>
>> I do see several big benefits of this approach
>>
>>- We can batching updates in a single call, right now we do not
>>use writer.add(documents) api from lucene, by batching updates this 
>> gonna
>>boost the performance of indexing
>>- One common problems with Solr now is we have lot of threads
>>doing indexing so that can ends up with many small segments. Using 
>> this
>>model we can have bigger segments so less merge cost
>>- Another huge reason here is after switching to this model, we
>>can remove tlog and use a distributed queue like Kafka, Pulsar. Since 
>> the
>>purpose of 

Re: Performance testing is necessary now

[Đạt Cao Mạnh]

>
> Another note here is problems come and go away in unpredictable ways.
Before SOLR-14665 I never thought about doing a performance test of
creating thousands of collections. The problem here is the same with our
tests, even Solr has a huge number of tests, bugs still happen here and
there, sometimes they are serious bugs. So no matter how good a performance
tool we have (not mentioning that we do not have a consistent, unified way
to do that) degrade performance can still happen in unpredictable ways.

Moreover, if a commit changes a particular codepath, like PeerSync class,
we do not have an available tool for that. Requiring people to write a tool
just to measure their changes to do a simple commit (and likely throw it
away) seems a big -1 to me, not to mention that bugs can arise in their
performance tools and numbers are hardly to be trusted.

Re: Solr: JoinAtHead seems problematic

[Đạt Cao Mạnh]

Sure!

Vào Th 6, 7 thg 8, 2020 lúc 07:33 Erick Erickson 
đã viết:

> Well, let me know if you have to dive into that and we can wrestle it to
> the ground. I suppose the short answer is “that code is correct if I
> remember correctly”….
>
> > On Aug 6, 2020, at 8:22 PM, Đạt Cao Mạnh 
> wrote:
> >
> > Thank Erick,
> >
> > I'm not fully understand it, but it kinda makes sense somehow.
> >
> > Thank you!
> >
> > On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson 
> wrote:
> > Dat:
> >
> > That’s a confusingly-named variable, surely needs a comment. Remembering
> from a long time ago trying to work with PreferredLeader, the problem is
> that you can’t _replace_ the head because that’s the one that actually is
> the leader. You have to spoof that by inserting a node that points to the
> leader, then making the leader go away so election takes place. IIRC (and
> lots may have changed since then), you wind up with a situation where
> >
> > znode0 is the current leader
> > znode1 points to znode0
> > znode2 _also_ points to znode0
> > znode3 points to znode1
> > znode 4 points to znode3
> >
> > znode1 here was the original znode put in the queue to become the next
> leader. znode2 is the one added by the code you’re looking at. When leader
> election actually happens, this situation is detected and znode2 becomes
> the leader and znode3 is changed to point to znode2 WARNING: This is what I
> remember from code I worked on a long time ago, it may have been changed a
> lot since then. But I’m fairly sure that’s what’s behind that code.
> >
> > Best,
> > Erick
> >
> >
> >
> > > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt  wrote:
> > >
> > > Hi guys,
> > >
> > > When I look at these lines,
> > > if(joinAtHead){
> > >   log.debug("Node {} trying to join election at the head", id);
> > >   List nodes =
> OverseerTaskProcessor.getSortedElectionNodes(zkClient, shardsElectZkPath);
> > >   if(nodes.size() <2){
> > > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id +
> "-n_", null,
> > > CreateMode.EPHEMERAL_SEQUENTIAL, false);
> > >   } else {
> > > String firstInLine = nodes.get(1);
> > > log.debug("The current head: {}", firstInLine);
> > > Matcher m = LEADER_SEQ.matcher(firstInLine);
> > > if (!m.matches()) {
> > >   throw new IllegalStateException("Could not find regex match in:"
> > >   + firstInLine);
> > > }
> > > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1);
> > > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false);
> > >   }
> > > } else {
> > > the line firstInLine = nodes.get(1) seems problematic to me. Why do we
> get the middle of a sorted list and say that it is the first thing in line?
> Should I open an issue for this?
> > >
> > > Thanks
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> > --
> > Best regards,
> > Cao Mạnh Đạt
> > E-mail: caomanhdat...@gmail.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: Solr: JoinAtHead seems problematic

[Đạt Cao Mạnh]

Thank Erick,

I'm not fully understand it, but it kinda makes sense somehow.

Thank you!

On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson 
wrote:

> Dat:
>
> That’s a confusingly-named variable, surely needs a comment. Remembering
> from a long time ago trying to work with PreferredLeader, the problem is
> that you can’t _replace_ the head because that’s the one that actually is
> the leader. You have to spoof that by inserting a node that points to the
> leader, then making the leader go away so election takes place. IIRC (and
> lots may have changed since then), you wind up with a situation where
>
> znode0 is the current leader
> znode1 points to znode0
> znode2 _also_ points to znode0
> znode3 points to znode1
> znode 4 points to znode3
>
> znode1 here was the original znode put in the queue to become the next
> leader. znode2 is the one added by the code you’re looking at. When leader
> election actually happens, this situation is detected and znode2 becomes
> the leader and znode3 is changed to point to znode2 WARNING: This is what I
> remember from code I worked on a long time ago, it may have been changed a
> lot since then. But I’m fairly sure that’s what’s behind that code.
>
> Best,
> Erick
>
>
>
> > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt  wrote:
> >
> > Hi guys,
> >
> > When I look at these lines,
> > if(joinAtHead){
> >   log.debug("Node {} trying to join election at the head", id);
> >   List nodes =
> OverseerTaskProcessor.getSortedElectionNodes(zkClient, shardsElectZkPath);
> >   if(nodes.size() <2){
> > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id +
> "-n_", null,
> > CreateMode.EPHEMERAL_SEQUENTIAL, false);
> >   } else {
> > String firstInLine = nodes.get(1);
> > log.debug("The current head: {}", firstInLine);
> > Matcher m = LEADER_SEQ.matcher(firstInLine);
> > if (!m.matches()) {
> >   throw new IllegalStateException("Could not find regex match in:"
> >   + firstInLine);
> > }
> > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1);
> > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false);
> >   }
> > } else {
> > the line firstInLine = nodes.get(1) seems problematic to me. Why do we
> get the middle of a sorted list and say that it is the first thing in line?
> Should I open an issue for this?
> >
> > Thanks
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: SolrClient and making requests asynchronously

[Đạt Cao Mạnh]

The new API seems good to me. it does be able to handle all cases : future,
listener and error handling.

On Sat, Aug 1, 2020 at 10:15 AM David Smiley 
wrote:

> Noble: Those sound like some big and bold ideas that are deserving of a
> separate conversation?  My proposal here is based on the APIs we have today.
>
> ~ David
>
>
> On Fri, Jul 31, 2020 at 10:06 PM Noble Paul  wrote:
>
>> I would also wish to deprecate all the public APIs which uses concrete
>> classes and move over to interfaces.
>>
>> The objectives are.
>> * We should be able to use POJOs that help with strong typing
>> * We should be able to easily switch between JSON/javabin/XML or even
>> well known protocols like protobuf
>>
>> On Sat, Aug 1, 2020 at 12:02 PM Noble Paul  wrote:
>> >
>> > Thanks David for bringing this up.
>> >
>> > I want us to stop using concrete classes. We should exclusively use
>> > interfaces in our public APIs.
>> >
>> > We should stop using NamedList and start using this interface
>> >
>> >
>> https://github.com/apache/lucene-solr/blob/b91b461632b19c9488926a9302126a2158df3298/solr/solrj/src/java/org/apache/solr/common/util/SimpleMap.java
>> >
>> > NamedList will implement this interface too
>> >
>> > The SolrRequest is an abstract class and it has a huge surface area.
>> > We must create a simple small interface for this as will
>> >
>> >
>> >
>> >
>> > On Sat, Aug 1, 2020 at 6:25 AM David Smiley  wrote:
>> > >
>> > > Hello devs,
>> > >
>> > > I'd like to have an API design discussion here on the dev list
>> concerning adding asynchronous request semantics to SolrClient.  I think
>> the SolrClient APIs require great peer-review consideration and so I'm
>> having this discussion here instead of a JIRA issue.
>> > >
>> > > Background: Sometimes, a SolrJ user (including Solr itself) may wish
>> to issue a request but not block/wait for the response because it can do
>> other useful work before eventually needing the results.  For example,
>> maybe the user has multiple requests to send to Solr that can be done in
>> parallel and _then_ process the results.  This is in fact what Solr needs
>> internally for during distributed-search (see HttpShardHandler) and during
>> distributed-indexing (see ConcurrentUpdateHttp2SolrClient).
>> > >
>> > > Why?:  Greater efficiency.  This can be accomplished easily in a
>> generic fashion with threads (e.g.
>> CompletableFuture.supplyAsync(Supplier,Executor)) with use of the
>> SolrClient concurrently. However, this can result in lots of threads and
>> context switching.  I really like Cao Dat's explanation in the description
>> here:  https://issues.apache.org/jira/browse/SOLR-14354 Thanks to
>> HTTP/2, there is a new approach in which the underlying HTTP client can
>> handle the asynchronous nature more efficiently with minimal threads.
>> Complete plumbing of this implies that SolrClient (and/or its derivatives)
>> need a similar async mechanism.  Disclaimer:  I haven't measured any of
>> this but am piggybacking off of Cao's's insights on SOLR-14354
>> > >
>> > > Where?:  An async API _could_ go only on some SolrClient classes that
>> natively support it, avoiding changing SolrClient itself.  Maybe this is
>> what should occur first before "graduating" the method to SolrClient where
>> we devise a default approach, although I would prefer just putting it on
>> SolrClient.  The default approach might be configured to throw
>> UnsupportedOperationException, or perhaps might simply use an Executor to
>> get it done in an obvious way (assuming we can get ahold of an Executor
>> somewhere?).  If you're writing a delegating SolrClient (which I've done in
>> the past), you might want to take-care to delegate this method.
>> > > Another aspect of "Where" is whether SolrRequest should additionally
>> have an API alternative to "process" which is currently synchronous and
>> calls out to SolrClient.request(this).
>> > >
>> > > What?:  What should this API look like?  This is my primary interest
>> right now and the meat of the discussion.
>> > >
>> > > SolrClient's primary signature that actually does the work
>> (synchronously) is this:
>> > >
>> > > public abstract NamedList
>> request(@SuppressWarnings({"rawtypes"})final SolrRequest request, String
>> collection)
>> > > throws SolrServerException, IOException;
>> > >
>> > > I don't like the "collection" there as it's redundant with either the
>> configured SolrClient default or a setting in SolrRequest, but I digress
>> from the important matter at hand.
>> > >
>> > > In SOLR-14354, recently committed by Cao Dat destined for Solr 8.7,
>> there is a new (undocumented) method on Http2SolrClient (*not* SolrClient):
>> > >
>> > > public Cancellable asyncRequest(@SuppressWarnings({"rawtypes"})
>> SolrRequest solrRequest, String collection,
>> AsyncListener> asyncListener) {
>> > >
>> > > So firstly, it's only on Http2SolrClient, which means if you're using
>> CloudHttp2SolrClient (which does not subclass it, counterintuitively to
>> 

Re: Welcome Michael Sokolov to the PMC

[Đạt Cao Mạnh]

Congrats Michael!

On Sat, Jul 4, 2020 at 4:40 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Congrats and welcome, Mike!
>
> On Sat, Jul 4, 2020 at 2:21 AM Yonik Seeley  wrote:
>
>> Congrats Michael!
>> -Yonik
>>
>>
>> On Fri, Jul 3, 2020 at 7:57 AM Adrien Grand  wrote:
>>
>>> I am pleased to announce that Michael Sokolov has accepted the PMC's
>>> invitation to join.
>>>
>>> Welcome Michael!
>>>
>>> --
>>> Adrien
>>>
>>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.5 release

[Đạt Cao Mạnh]

+1

On Tue, Feb 18, 2020 at 8:38 AM Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> +1
>
> On Tue, Feb 18, 2020 at 7:58 AM Alan Woodward 
> wrote:
>
>> Hi all,
>>
>> It’s been a while since we released lucene-solr 8.4, and we’ve
>> accumulated quite a few nice new features since then.  I’d like to
>> volunteer to be a release manager for an 8.5 release.  If there's
>> agreement, then I plan to cut the release branch two weeks today, on
>> Tuesday 3rd March.
>>
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>


-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Đạt Cao Mạnh]

Congrats Anshum!!

On Thu, 16 Jan 2020 at 08:43, Michael McCandless 
wrote:

> Congrats Anshum!  It's great fun!
>
> Mike
>
> On Wed, Jan 15, 2020 at 6:24 PM Steve Rowe  wrote:
>
>> Congrats Anshum!
>>
>> --
>> Steve
>>
>>
>> On Jan 15, 2020, at 4:15 PM, Cassandra Targett 
>> wrote:
>>
>> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
>> President position.
>>
>> This year we have nominated and elected Anshum Gupta as the Chair, a
>> decision that the board approved in its January 2020 meeting.
>>
>> Congratulations, Anshum!
>>
>> Cassandra
>>
>>
>> --
> Mike McCandless
>
> http://blog.mikemccandless.com
>
-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: Welcome Houston Putman as Lucene/Solr committer

[Đạt Cao Mạnh]

Congrats and welcome Houston!!

On Thu, 14 Nov 2019 at 11:54, David Smiley  wrote:

> Congrats Houston!  Woohoo!
>
> On Thu, Nov 14, 2019 at 3:58 AM Anshum Gupta 
> wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Houston Putman as the latest Lucene/Solr
>> committer!
>>
>> Houston has been involved with the community since 2013, when he first
>> contributed the Analytics contrib module. Since then he has been involved
>> with the community, participated in conferences and spoken about his work
>> with Lucene/Solr. In the recent past, he has been involved with getting
>> Solr to scale on Kubernetes.
>>
>> Looking forward to your commits to the Apache Lucene/Solr project :)
>>
>> Congratulations and welcome, Houston! It's a tradition to introduce
>> yourself with a brief bio.
>>
>> --
>> Anshum Gupta
>>
> --
> Sent from Gmail Mobile
>
-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.3 release

[Đạt Cao Mạnh]

Hi Ishan,

I pushed the fix to branch_8_3.

On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl  wrote:

> Ishan, I'd like to get https://issues.apache.org/jira/browse/SOLR-13665
> included, since without it Solr won't work with SSL against Zookeeper.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
>
> Hi Ishan,
>
> Thanks for taking care of the release. We have a blocker in Lucene (see
> https://issues.apache.org/jira/browse/LUCENE-8920). I remember that was
> an issue for the 8.2.0 release and it was reverted and naked as a blocker
> for this release. Maybe we should completely reverted until we have a
> better solution? let see what Mike thinks about it.
>
> Thanks,
>
> Ignacio
>
> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:
>
>> Hi,
>>
>> I also had a customer complaining about this. I have the feeling it also
>> happens from time to time during inter node comm, which uses solrj, too.
>>
>> Uwe
>>
>> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>:
>>>
>>> +1, Dat! Please go ahead.
>>>
>>> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>>>
>>>> It’s marked as Minor in Jira, but after reading the description it
>>>> sounds scary - IMHO it should be at least well investigated before 8.3 in
>>>> order to determine whether it causes real damage (apart from looking scary
>>>> and filling the logs).
>>>>
>>>> +1 from me.
>>>>
>>>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>>>>
>>>> Hi Ishan, guys
>>>>
>>>> I want to include the fix for
>>>> https://issues.apache.org/jira/browse/SOLR-13293 in this release.
>>>> Hoping that is ok!
>>>>
>>>> Thanks!
>>>>
>>>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>>>>
>>>>> ASF Jenkins Jobs also reconfigured.
>>>>>
>>>>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if
>>>>> that one is still needed. All other jobs are 8.3 now.
>>>>>
>>>>> Uwe
>>>>>
>>>>> -
>>>>> Uwe Schindler
>>>>> Achterdiek 19, D-28357 Bremen
>>>>> https://www.thetaphi.de
>>>>> eMail: u...@thetaphi.de
>>>>>
>>>>> > -Original Message-
>>>>> > From: Uwe Schindler 
>>>>> > Sent: Tuesday, October 8, 2019 4:49 PM
>>>>> > To: dev@lucene.apache.org
>>>>> > Subject: RE: 8.3 release
>>>>> >
>>>>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>>>>> >
>>>>> > Uwe
>>>>> >
>>>>> > -
>>>>> > Uwe Schindler
>>>>> > Achterdiek 19, D-28357 Bremen
>>>>> > https://www.thetaphi.de
>>>>> > eMail: u...@thetaphi.de
>>>>> >
>>>>> > > -Original Message-
>>>>> > > From: Ishan Chattopadhyaya 
>>>>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>>>>> > > To: Lucene Dev ; Uwe Schindler
>>>>> > > ; Steve Rowe 
>>>>> > > Subject: Re: 8.3 release
>>>>> > >
>>>>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix.
>>>>> For
>>>>> > > any feature, please let me know to see how we can accommodate it
>>>>> > > safely.
>>>>> > > I'm planning to get myself familiarized with what I need to do for
>>>>> the
>>>>> > > ref guide release (simultaneously with the binary release). So,
>>>>> most
>>>>> > > likely, I'll be able to build artifacts in another week's time.
>>>>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please
>>>>> create a
>>>>> > > Jenkins branch for 8.3?
>>>>> > > Thanks,
>>>>> > > Ishan
>>>>> > >
>>>>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>>>>> > >  wrote:
>>>>> > > >
>>>>> > > > I'll cut the branch in 12-24 hours from now. If someone has
>>>>> anything
>&g

Re: 8.3 release

[Đạt Cao Mạnh]

Hi Ishan, guys

I want to include the fix for
https://issues.apache.org/jira/browse/SOLR-13293 in this release. Hoping
that is ok!

Thanks!

On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:

> ASF Jenkins Jobs also reconfigured.
>
> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that
> one is still needed. All other jobs are 8.3 now.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, October 8, 2019 4:49 PM
> > To: dev@lucene.apache.org
> > Subject: RE: 8.3 release
> >
> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Ishan Chattopadhyaya 
> > > Sent: Tuesday, October 8, 2019 4:32 PM
> > > To: Lucene Dev ; Uwe Schindler
> > > ; Steve Rowe 
> > > Subject: Re: 8.3 release
> > >
> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
> > > any feature, please let me know to see how we can accommodate it
> > > safely.
> > > I'm planning to get myself familiarized with what I need to do for the
> > > ref guide release (simultaneously with the binary release). So, most
> > > likely, I'll be able to build artifacts in another week's time.
> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
> > > Jenkins branch for 8.3?
> > > Thanks,
> > > Ishan
> > >
> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
> > >  wrote:
> > > >
> > > > I'll cut the branch in 12-24 hours from now. If someone has anything
> > > > to put into branch_8x now, please feel free.
> > > > If someone has a non-bugfix issue that they want to push in to 8.3
> > > > after the branch cut, but you're sure it will not disrupt the
> > > > stability of the release, please let me know and we can discuss on a
> > > > case-by-case basis.
> > > >
> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev 
> > > wrote:
> > > > >
> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
> > > > >
> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
> > >  wrote:
> > > > >>
> > > > >> Ishan, thanks for update.
> > > > >> May I propose to hold it for this week, beside of the severe
> issues you
> > > mentioned, I'd like to drop pretty neat JSON Query parser for Interval
> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 this week.
> > > > >>
> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
> > > :
> > > > >>>
> > > > >>> * Due to some unfinished and half merged work in SOLR-13661, we
> > are
> > > in
> > > > >>> a difficult position for a branch cutting today (as I had
> proposed).
> > > > >>> I have documented the options on how to deal with that
> immediately
> > > in
> > > > >>> that issue. I'll work to resolve the situation and cut a branch
> as
> > > > >>> soon as possible.
> > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed
> with the
> > > > >>> branch cutting.
> > > > >>>
> > > > >>> I'll take a look at the ref guide's simultaneous release as we
> reach
> > > > >>> closer to building the artifacts.
> > > > >>> Thanks,
> > > > >>> Ishan
> > > > >>>
> > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
> > >  wrote:
> > > > >>> >
> > > > >>> > As I’ve mentioned to some of you over the past couple of
> weeks, I
> > > want to propose that we don’t “release” the Ref Guide at all the way we
> > have
> > > been doing it.
> > > > >>> >
> > > > >>> > It deserves a separate thread, which since it’s come up a few
> times
> > > this week I should start now, but in essence, my idea is to no longer
> treat
> > the
> > > PDF as a release artifact that requires a vote, and publish the HTML
> as our
> > > primary version of the Ref Guide in effectively the same way we
> publish the
> > > javadocs (at the same time as the binary artifacts).
> > > > >>> >
> > > > >>> > Instead of highjacking this thread with that discussion since
> it has
> > > several aspects, let me send another mail on it where I can flesh it
> out
> > more
> > > and we can discuss there. I have the mail mostly queued up and ready to
> > go
> > > already.
> > > > >>> >
> > > > >>> > Cassandra
> > > > >>> > On Sep 18, 2019, 10:23 AM -0500, Gus Heck
> > ,
> > > wrote:
> > > > >>> >
> > > > >>> > I learned recently that it's actually all  documented here:
> > > https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-
> > > guide-publication-process
> > > > >>> >
> > > > >>> > On Tue, Sep 17, 2019 at 7:31 PM Ishan Chattopadhyaya
> > >  wrote:
> > > > >>> >>
> > > > >>> >> Hi Adrien,
> > > > >>> >> Indeed, meant to write about starting a vote.
> > > > >>> >>
> > > > >>> >> @Gus, I'll have to let Cassandra weigh in on this one as I'm
> not
> > very
> > > familiar with the ref guide release process.
> > > > >>> >>

Re: NVMe - SSD shredding due to Lucene :-)

[Đạt Cao Mạnh]

Thanks Uwe for keeping the Police up and running!

On Sat, 31 Aug 2019 at 11:20, Uwe Schindler  wrote:

> Hi all,
>
> I just wanted to inform you that I asked the provider of the Policeman
> Jenkins Server to replace the first of two NVMe SSDs, because it failed
> with fatal warnings due to too many writes and no more spare sectors:
>
> > root@serv1 ~ # nvme smart-log /dev/nvme0
> > Smart Log for NVME device:nvme0 namespace-id:
> > critical_warning: 0x1
> > temperature : 76 C
> > available_spare : 2%
> > available_spare_threshold   : 10%
> > percentage_used : 67%
> > data_units_read : 62,129,054
> > data_units_written  : 648,788,135
> > host_read_commands  : 6,426,997,226
> > host_write_commands : 5,582,107,803
> > controller_busy_time: 86,754
> > power_cycles: 21
> > power_on_hours  : 20,252
> > unsafe_shutdowns: 16
> > media_errors: 0
> > num_err_log_entries : 0
> > Warning Temperature Time: 7855
> > Critical Composite Temperature Time : 0
> > Temperature Sensor 1: 76 C
> > Thermal Management T1 Trans Count   : 0
> > Thermal Management T2 Trans Count   : 0
> > Thermal Management T1 Total Time: 0
> > Thermal Management T2 Total Time: 0
>
> The second one looks a bit better, but will be changed later, too. I have
> no idea what a data unit is (512 bytes, 2048 bytes,... - I think one LBA).
>
> So we are really shredding SSDs with Lucene tests 
>
> Uwe
>
> P.S.: The replacement is currently going on...
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Thanks Steve!

On Wed, 10 Jul 2019 at 22:35, Steve Rowe  wrote:

> I've disabled the ASF Jenkins 8.1 jobs.
>
> --
> Steve
>
> On Jul 10, 2019, at 9:39 AM, Đạt Cao Mạnh  wrote:
>
> Hi Adrien,
>
> Yeah, I am good with skipping/canceling 8.1.2 and focusing on 8.2 now.
>
> On Wed, 10 Jul 2019 at 19:11, Adrien Grand  wrote:
>
>> Hi Đạt,
>>
>> What do you think of focusing on 8.2 now, as Shalin suggested? Ignacio
>> had suggested cutting the 8.2 branch today initially so 8.2 could be
>> out pretty soon. Moreover if we want to move forward with 8.1.2, we
>> will likely have to delay 8.2 at this point.
>>
>> On Fri, Jul 5, 2019 at 8:42 AM Adrien Grand  wrote:
>> >
>> > Agreed with Shalin, we might want to focus on 8.2 at this point.
>> >
>> > On Fri, Jul 5, 2019 at 8:38 AM Shalin Shekhar Mangar
>> >  wrote:
>> > >
>> > > Thanks Dat.
>> > >
>> > > I don't think we should release a broken version without a fix for
>> SOLR-13413. A workaround for SOLR-13413 exists (forcing http1.1 for
>> inter-node requests) but we don't test that configuration anymore in Sole
>> so I am hesitant to suggest it.
>> > >
>> > > I think that either we agree to upgrade jetty to 9.4.19 in this point
>> release or we scrap it altogether and focus on 8.2.
>> > >
>> > > On Thu, Jul 4, 2019 at 4:54 PM Đạt Cao Mạnh 
>> wrote:
>> > >>
>> > >> Thanks Uwe!
>> > >>
>> > >> Hi guys, Ishan,
>> > >> When I tryied to build the RC1 for branch_8_1. I did see this
>> failure on test HttpPartitionWithTlogReplicasTest
>> > >>
>> > >> 215685 ERROR
>> (updateExecutor-537-thread-1-processing-x:collDoRecoveryOnRestart_shard1_replica_t1
>> r:core_node3 null n:127.0.0.1:55000_t_ayt%2Fs c:collDoRecoveryOnRestart
>> s:shard1) [n:127.0.0.1:55000_t_ayt%2Fs c:collDoRecoveryOnRestart
>> s:shard1 r:core_node3 x:collDoRecoveryOnRestart_shard1_replica_t1]
>> o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
>> SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode:
>> http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
>> to
>> http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
>> > >>   => java.io.IOException: java.net.ConnectException:
>> Connection refused
>> > >> at
>> org.eclipse.jetty.client.util.DeferredContentProvider.flush(DeferredContentProvider.java:193)
>> > >> java.io.IOException: java.net.ConnectException: Connection refused
>> > >> at
>> org.eclipse.jetty.client.util.DeferredContentProvider.flush(DeferredContentProvider.java:193)
>> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
>> > >> at
>> org.eclipse.jetty.client.util.OutputStreamContentProvider$DeferredOutputStream.flush(OutputStreamContentProvider.java:152)
>> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
>> > >> at
>> org.eclipse.jetty.client.util.OutputStreamContentProvider$DeferredOutputStream.write(OutputStreamContentProvider.java:146)
>> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
>> > >> at
>> org.apache.solr.common.util.FastOutputStream.flush(FastOutputStream.java:216)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.common.util.FastOutputStream.flushBuffer(FastOutputStream.java:209)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:169)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.marshal(JavaBinUpdateRequestCodec.java:102)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.client.solrj.impl.BinaryRequestWriter.write(BinaryRequestWriter.java:83)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.client.solrj.impl.Http2SolrClient.send(Http2SolrClient.java:337)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:231)
>> ~[java/:?]
>> > >> at
>> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
>> ~[java/:?]
>> > >> at
>> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
>> ~[metrics-core-4.0.5.jar:4.0.5]
>> > >> at
>> org.apache.solr.common.util.

Re: Lucene/Solr 8.2.0

[Đạt Cao Mạnh]

Hi Ignacio,

8.1.2 bugfix release will cancelled. You can go ahead with 8.2 release.

Thanks!

On Wed, 10 Jul 2019 at 20:38, Tomoko Uchida 
wrote:

> Hi,
> I opened a blocker issue a while ago for release 8.2:
> https://issues.apache.org/jira/browse/LUCENE-8907
>
> Sorry about that, I noticed the backwards incompatibility we have to
> deal with today. If there are no objections, I will revert the all
> related commits from the branch_8x and 8_2 in a few days.
>
> Thanks,
> Tomoko
>
> 2019年7月10日(水) 22:02 Ignacio Vera :
> >
> > Hi,
> >
> > All the issues listed above has been already committed and I see no
> blockers for release 8.2. I will cut the branch tomorrow around 10am CEST
> and I will wait for the decision on the bug release 8.1.2 to schedule the
> build of the first release candidate. Please let us know if this is
> troublesome for you.
> >
> > Thanks,
> >
> > Ignacio
> >
> >
> > On Tue, Jul 2, 2019 at 2:59 AM Joel Bernstein 
> wrote:
> >>
> >> I've got one issue that I'd like to get in (
> https://issues.apache.org/jira/browse/SOLR-13589), which I should have
> wrapped up in a day or two. +1 for around July 10th.
> >>
> >> On Mon, Jul 1, 2019 at 5:14 PM Nicholas Knize  wrote:
> >>>
> >>> +1 for starting the 8.2 release process. I think it would be good to
> get the LUCENE-8632 feature into 8.2 along with the BKD improvements and
> changes in LUCENE- and LUCENE-8896
> >>>
> >>> Nicholas Knize, Ph.D., GISP
> >>> Geospatial Software Guy  |  Elasticsearch
> >>> Apache Lucene PMC Member and Committer
> >>> nkn...@apache.org
> >>>
> >>>
> >>> On Wed, Jun 26, 2019 at 9:34 AM Ignacio Vera 
> wrote:
> 
>  Hi all,
> 
>  8.1 has been released on May 16th and we have new features,
> enhancements and fixes that are not released yet so I'd like to start
> thinking in releasing Lucene/Solr 8.2.0.
> 
>  I can create the 8.2 branch in two weeks time (around July 10th) and
> build the first RC by the end of that week if that works for everyone.
> Please let me know if there are bug fixes that needs to be fixed in 8.2 and
> might not be ready by then.
> 
>  Cheers,
> 
>  Ignacio
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Adrien,

Yeah, I am good with skipping/canceling 8.1.2 and focusing on 8.2 now.

On Wed, 10 Jul 2019 at 19:11, Adrien Grand  wrote:

> Hi Đạt,
>
> What do you think of focusing on 8.2 now, as Shalin suggested? Ignacio
> had suggested cutting the 8.2 branch today initially so 8.2 could be
> out pretty soon. Moreover if we want to move forward with 8.1.2, we
> will likely have to delay 8.2 at this point.
>
> On Fri, Jul 5, 2019 at 8:42 AM Adrien Grand  wrote:
> >
> > Agreed with Shalin, we might want to focus on 8.2 at this point.
> >
> > On Fri, Jul 5, 2019 at 8:38 AM Shalin Shekhar Mangar
> >  wrote:
> > >
> > > Thanks Dat.
> > >
> > > I don't think we should release a broken version without a fix for
> SOLR-13413. A workaround for SOLR-13413 exists (forcing http1.1 for
> inter-node requests) but we don't test that configuration anymore in Sole
> so I am hesitant to suggest it.
> > >
> > > I think that either we agree to upgrade jetty to 9.4.19 in this point
> release or we scrap it altogether and focus on 8.2.
> > >
> > > On Thu, Jul 4, 2019 at 4:54 PM Đạt Cao Mạnh 
> wrote:
> > >>
> > >> Thanks Uwe!
> > >>
> > >> Hi guys, Ishan,
> > >> When I tryied to build the RC1 for branch_8_1. I did see this failure
> on test HttpPartitionWithTlogReplicasTest
> > >>
> > >> 215685 ERROR
> (updateExecutor-537-thread-1-processing-x:collDoRecoveryOnRestart_shard1_replica_t1
> r:core_node3 null n:127.0.0.1:55000_t_ayt%2Fs c:collDoRecoveryOnRestart
> s:shard1) [n:127.0.0.1:55000_t_ayt%2Fs c:collDoRecoveryOnRestart s:shard1
> r:core_node3 x:collDoRecoveryOnRestart_shard1_replica_t1]
> o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
> SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode:
> http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
> to
> http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
> > >>   => java.io.IOException: java.net.ConnectException:
> Connection refused
> > >> at
> org.eclipse.jetty.client.util.DeferredContentProvider.flush(DeferredContentProvider.java:193)
> > >> java.io.IOException: java.net.ConnectException: Connection refused
> > >> at
> org.eclipse.jetty.client.util.DeferredContentProvider.flush(DeferredContentProvider.java:193)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> > >> at
> org.eclipse.jetty.client.util.OutputStreamContentProvider$DeferredOutputStream.flush(OutputStreamContentProvider.java:152)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> > >> at
> org.eclipse.jetty.client.util.OutputStreamContentProvider$DeferredOutputStream.write(OutputStreamContentProvider.java:146)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> > >> at
> org.apache.solr.common.util.FastOutputStream.flush(FastOutputStream.java:216)
> ~[java/:?]
> > >> at
> org.apache.solr.common.util.FastOutputStream.flushBuffer(FastOutputStream.java:209)
> ~[java/:?]
> > >> at
> org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:169)
> ~[java/:?]
> > >> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.marshal(JavaBinUpdateRequestCodec.java:102)
> ~[java/:?]
> > >> at
> org.apache.solr.client.solrj.impl.BinaryRequestWriter.write(BinaryRequestWriter.java:83)
> ~[java/:?]
> > >> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.send(Http2SolrClient.java:337)
> ~[java/:?]
> > >> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:231)
> ~[java/:?]
> > >> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
> ~[java/:?]
> > >> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
> ~[metrics-core-4.0.5.jar:4.0.5]
> > >> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[java/:?]
> > >> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_191]
> > >> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_191]
> > >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> > >> Suppressed: java.io.IOException: java.net.ConnectException:
> Connection refused
> > >> at
> org.eclipse.jetty.

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

ing up to try to start recovery
on replica core_node4 with url
http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
by increasing leader term
  => java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:1.8.0_191]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
~[?:1.8.0_191]
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111) ~[?:1.8.0_191]
at org.eclipse.jetty.http2.client.HTTP2Client.connect(HTTP2Client.java:397)
~[http2-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at
org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:146)
~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
at
org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:141)
~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
at org.eclipse.jetty.client.HttpClient$1.connect(HttpClient.java:619)
~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:596)
~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:589)
~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at
org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:181)
~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
~[java/:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_191]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
215690 INFO  (qtp175924403-2361) [n:127.0.0.1:55000_t_ayt%2Fs
c:collDoRecoveryOnRestart s:shard1 r:core_node3
x:collDoRecoveryOnRestart_shard1_replica_t1] o.a.s.c.ZkShardTerms
Successful update of terms at
/collections/collDoRecoveryOnRestart/terms/shard1 to
Terms{values={core_node3=2, core_node4=1}, version=3}

This seems relates to the fix for SOLR-13413 when only
http2-http-client-transport
get upgraded to 9.4.19. The similar failure does not happen in branch_8x or
master. I tried to switch back http2-http-client-transport 9.4.14 and the
problem seems go away. So there are 2 solutions now for 8.1.2

   1. 8.1.2 will be released without SOLR-13413.
   2. upgrade Jetty to 9.4.19 for 8.1.2 release.

I personally prefer the second option since there are no (or I think so)
suspicious failures on master and branch_8x. What do you guys think?

Thanks!

On Thu, Jul 4, 2019 at 12:48 PM Uwe Schindler  wrote:

> No,
>
> Running with Java 9 is optional. You have to tell smoker to do this,
> otherwise it enforces Java 8 only.
>
> Uwe
>
> Am July 4, 2019 2:22:40 AM UTC schrieb "Đạt Cao Mạnh" <
> caomanhdat...@gmail.com>:
>>
>> Thanks Uwe, Steve
>>
>> I'm not familiar with the pipeline of smoker-release but I assumpt that
>> the same pipeline will be run during release process in my machine and
>> anyone who do the vote. So It won't be a blocker for this release and I can
>> continue with the release process, is that correct?
>>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>


-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Thanks Uwe, Steve

I'm not familiar with the pipeline of smoker-release but I assumpt that the
same pipeline will be run during release process in my machine and anyone
who do the vote. So It won't be a blocker for this release and I can
continue with the release process, is that correct?

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Anshum,

I kinda think we should not do that since 8.1.2 is a bug fix only release.

On Wed, Jul 3, 2019 at 11:56 PM Anshum Gupta  wrote:

> Hi Dat,
>
> Can we also get SOLR-13507
> <https://issues.apache.org/jira/browse/SOLR-13507> in for 8.1.2 ?
>
> On Wed, Jul 3, 2019 at 4:55 AM Đạt Cao Mạnh 
> wrote:
>
>> Thanks Andrzej!
>>
>> On Wed, Jul 3, 2019 at 6:41 PM Andrzej Białecki  wrote:
>>
>>> Dat,
>>>
>>> The fix for SOLR-13583 has been committed to branch_8_1.
>>>
>>> On 3 Jul 2019, at 04:56, Đạt Cao Mạnh  wrote:
>>>
>>> Hi Steve,
>>>
>>> I'm seeing this failure
>>>
>>> [smoker] subprocess.CalledProcessError: Command 'export
>>> JAVA_HOME="/home/jenkins/tools/java/latest1.9"
>>> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
>>> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
>>> returned non-zero exit status 127
>>> on
>>>
>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>>>
>>> It seems that the /home/jenkins/tools/java/latest1.9/bin does not
>>> present in the system. Can you work on this, if that is not possible can
>>> you show me how I can connect to that jenkins box?
>>>
>>> Thanks a lot!
>>>
>>> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh 
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I'm seeing several Lucene test failures for branch_8_1. Should they be
>>>> marked as badApples?
>>>>
>>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
>>>>
>>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>>>>
>>>>
>>>> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera 
>>>> wrote:
>>>>
>>>>> Thanks! it is done.
>>>>>
>>>>> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
>>>>> wrote:
>>>>>
>>>>>> Ok, I'm hoping these two are these last ones.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> *Best regards,*
>>>> *Cao Mạnh Đạt*
>>>> *E-mail: caomanhdat...@gmail.com *
>>>>
>>>
>>>
>>> --
>>> *Best regards,*
>>> *Cao Mạnh Đạt*
>>> *E-mail: caomanhdat...@gmail.com *
>>>
>>>
>>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>
>
> --
> Anshum Gupta
>


-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Thanks Andrzej!

On Wed, Jul 3, 2019 at 6:41 PM Andrzej Białecki  wrote:

> Dat,
>
> The fix for SOLR-13583 has been committed to branch_8_1.
>
> On 3 Jul 2019, at 04:56, Đạt Cao Mạnh  wrote:
>
> Hi Steve,
>
> I'm seeing this failure
>
> [smoker] subprocess.CalledProcessError: Command 'export
> JAVA_HOME="/home/jenkins/tools/java/latest1.9"
> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
> returned non-zero exit status 127
> on
>
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>
> It seems that the /home/jenkins/tools/java/latest1.9/bin does not present
> in the system. Can you work on this, if that is not possible can you show
> me how I can connect to that jenkins box?
>
> Thanks a lot!
>
> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh 
> wrote:
>
>> Hi guys,
>>
>> I'm seeing several Lucene test failures for branch_8_1. Should they be
>> marked as badApples?
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
>>
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>>
>>
>> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  wrote:
>>
>>> Thanks! it is done.
>>>
>>> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
>>> wrote:
>>>
>>>> Ok, I'm hoping these two are these last ones.
>>>>
>>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>
>
> --
> *Best regards,*
> *Cao Mạnh Đạt*
> *E-mail: caomanhdat...@gmail.com *
>
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Steve,

I'm seeing this failure

[smoker] subprocess.CalledProcessError: Command 'export
JAVA_HOME="/home/jenkins/tools/java/latest1.9"
PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
returned non-zero exit status 127
on
https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console

It seems that the /home/jenkins/tools/java/latest1.9/bin does not present
in the system. Can you work on this, if that is not possible can you show
me how I can connect to that jenkins box?

Thanks a lot!

On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh  wrote:

> Hi guys,
>
> I'm seeing several Lucene test failures for branch_8_1. Should they be
> marked as badApples?
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
>
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>
>
> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  wrote:
>
>> Thanks! it is done.
>>
>> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
>> wrote:
>>
>>> Ok, I'm hoping these two are these last ones.
>>>
>>
>
> --
> *Best regards,*
> *Cao Mạnh Đạt*
> *E-mail: caomanhdat...@gmail.com *
>


-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi guys,

I'm seeing several Lucene test failures for branch_8_1. Should they be
marked as badApples?
https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/


On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  wrote:

> Thanks! it is done.
>
> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
> wrote:
>
>> Ok, I'm hoping these two are these last ones.
>>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Ok, I'm hoping these two are these last ones.

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Sure Ignacio!

On Tue, Jun 25, 2019 at 4:02 PM Ignacio Vera  wrote:

> Hi,
>
> I would like to backport bug fix LUCENE-8775 that fixes some failures in
> the polygon Tessellator when a polygon contain a hole sharing a vertex with
> the polygon. Is that ok?
>
> Thanks,
>
> Ignacio
>
> On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe  wrote:
>
>> Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve
>>
>> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh 
>> wrote:
>>
>> Hi Uwe, Steve.
>>
>> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how
>> to enable them on https://builds.apache.org/view/L/view/Lucene/
>>
>> Thanks.
>>
>> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sure Dat, sounds good.
>>>
>>> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh 
>>> wrote:
>>> >
>>> > Hi Ishan,
>>> >
>>> > If upgrade Jetty seems too much for a bug fix release, I will try to
>>> upgrade only part that affect SOLR-13413 (one module). Then see how tests
>>> will behave then. Does that sound good?
>>> >
>>> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>
>>> >> Have we vetted all other changes to Jetty? Are we sure that they
>>> don't introduce a different regression?
>>> >>
>>> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, 
>>> wrote:
>>> >>>
>>> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created
>>> https://issues.apache.org/jira/browse/SOLR-13541 specifically for the
>>> Jetty upgrade.
>>> >>>
>>> >>> Kevin Risden
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh <
>>> caomanhdat...@gmail.com> wrote:
>>> >>>>
>>> >>>> Hi David, yeah sure, that bug fix seems important.
>>> >>>> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix:
>>> SOLR-13413). Do you guys have any objections?
>>> >>>>
>>> >>>> On Wed, Jun 12, 2019 at 3:40 PM David Smiley <
>>> david.w.smi...@gmail.com> wrote:
>>> >>>>>
>>> >>>>> Yes thanks for volunteering.  Also, lets get this serious bug fix
>>> in:  https://issues.apache.org/jira/browse/SOLR-13523
>>> >>>>>
>>> >>>>> ~ David Smiley
>>> >>>>> Apache Lucene/Solr Search Developer
>>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>> >>>>>
>>> >>>>>
>>> >>>>> On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh <
>>> caomanhdat...@gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> Just right after the 8.1.1 release has been published we’ve
>>> discovered a serious bug in BasicAuthentication which affect all released
>>> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found
>>> in SOLR-13510.
>>> >>>>>>
>>> >>>>>> I’m volunteering to do this release, if there are no objections,
>>> and I’d like to create a RC early next week.
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> Best regards,
>>> >>>>>> Cao Mạnh Đạt
>>> >>>>>> E-mail: caomanhdat...@gmail.com
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Best regards,
>>> >>>> Cao Mạnh Đạt
>>> >>>> E-mail: caomanhdat...@gmail.com
>>> >
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Cao Mạnh Đạt
>>> > E-mail: caomanhdat...@gmail.com
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>>
>>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Uwe, Steve.

Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how
to enable them on https://builds.apache.org/view/L/view/Lucene/

Thanks.

On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Sure Dat, sounds good.
>
> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh 
> wrote:
> >
> > Hi Ishan,
> >
> > If upgrade Jetty seems too much for a bug fix release, I will try to
> upgrade only part that affect SOLR-13413 (one module). Then see how tests
> will behave then. Does that sound good?
> >
> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>
> >> Have we vetted all other changes to Jetty? Are we sure that they don't
> introduce a different regression?
> >>
> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden,  wrote:
> >>>
> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created
> https://issues.apache.org/jira/browse/SOLR-13541 specifically for the
> Jetty upgrade.
> >>>
> >>> Kevin Risden
> >>>
> >>>
> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh 
> wrote:
> >>>>
> >>>> Hi David, yeah sure, that bug fix seems important.
> >>>> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix:
> SOLR-13413). Do you guys have any objections?
> >>>>
> >>>> On Wed, Jun 12, 2019 at 3:40 PM David Smiley <
> david.w.smi...@gmail.com> wrote:
> >>>>>
> >>>>> Yes thanks for volunteering.  Also, lets get this serious bug fix
> in:  https://issues.apache.org/jira/browse/SOLR-13523
> >>>>>
> >>>>> ~ David Smiley
> >>>>> Apache Lucene/Solr Search Developer
> >>>>> http://www.linkedin.com/in/davidwsmiley
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh <
> caomanhdat...@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Just right after the 8.1.1 release has been published we’ve
> discovered a serious bug in BasicAuthentication which affect all released
> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found
> in SOLR-13510.
> >>>>>>
> >>>>>> I’m volunteering to do this release, if there are no objections,
> and I’d like to create a RC early next week.
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>> Cao Mạnh Đạt
> >>>>>> E-mail: caomanhdat...@gmail.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Cao Mạnh Đạt
> >>>> E-mail: caomanhdat...@gmail.com
> >
> >
> >
> > --
> > Best regards,
> > Cao Mạnh Đạt
> > E-mail: caomanhdat...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: VOTE: Apache Solr Reference Guide for Solr 8.1

[Đạt Cao Mạnh]

+1

On Fri, Jun 14, 2019 at 9:39 PM Jan Høydahl  wrote:

> +1
>
> Jan Høydahl
>
> 12. jun. 2019 kl. 16:47 skrev Cassandra Targett :
>
> Please vote to release the Solr Reference Guide for 8.1
>
> The PDF artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.1-RC1/
>
> $ cat apache-solr-ref-guide-8.1.pdf.sha512
> cc76882fb3061fa03d1aa291d9705c1df17f948ff47f3f7d6a18e8ddef907f1c74f078ed482f7f5e04b7c6779a88ad85297cd31ae03570db2acc5930ba2feaf0
>  apache-solr-ref-guide-8.1.pdf
>
> The HTML version is also available:
> https://lucene.apache.org/solr/guide/8_1
>
> Here's my +1.
>
> Thanks,
> Cassandra
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Ishan,

If upgrade Jetty seems too much for a bug fix release, I will try to
upgrade only part that affect SOLR-13413
<https://issues.apache.org/jira/browse/SOLR-13413> (one module). Then see
how tests will behave then. Does that sound good?

On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Have we vetted all other changes to Jetty? Are we sure that they don't
> introduce a different regression?
>
> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden,  wrote:
>
>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created
>> https://issues.apache.org/jira/browse/SOLR-13541 specifically for the
>> Jetty upgrade.
>>
>> Kevin Risden
>>
>>
>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh 
>> wrote:
>>
>>> Hi David, yeah sure, that bug fix seems important.
>>> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413
>>> <https://issues.apache.org/jira/browse/SOLR-13413>). Do you guys have
>>> any objections?
>>>
>>> On Wed, Jun 12, 2019 at 3:40 PM David Smiley 
>>> wrote:
>>>
>>>> Yes thanks for volunteering.  Also, lets get this serious bug fix in:
>>>> https://issues.apache.org/jira/browse/SOLR-13523
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Just right after the 8.1.1 release has been published we’ve
>>>>> discovered a serious bug in BasicAuthentication which affect all released
>>>>> versions of Solr including 8.0, 8.1, 8.1.1. Details of the bug can be 
>>>>> found
>>>>> in SOLR-13510.
>>>>>
>>>>> I’m volunteering to do this release, if there are no objections, and
>>>>> I’d like to create a RC early next week.
>>>>>
>>>>> --
>>>>> *Best regards,*
>>>>> *Cao Mạnh Đạt*
>>>>> *E-mail: caomanhdat...@gmail.com *
>>>>>
>>>>
>>>
>>> --
>>> *Best regards,*
>>> *Cao Mạnh Đạt*
>>> *E-mail: caomanhdat...@gmail.com *
>>>
>>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi David, yeah sure, that bug fix seems important.
I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413
<https://issues.apache.org/jira/browse/SOLR-13413>). Do you guys have any
objections?

On Wed, Jun 12, 2019 at 3:40 PM David Smiley 
wrote:

> Yes thanks for volunteering.  Also, lets get this serious bug fix in:
> https://issues.apache.org/jira/browse/SOLR-13523
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh 
> wrote:
>
>> Hi,
>>
>> Just right after the 8.1.1 release has been published we’ve discovered a
>> serious bug in BasicAuthentication which affect all released versions of
>> Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found in
>> SOLR-13510.
>>
>> I’m volunteering to do this release, if there are no objections, and I’d
>> like to create a RC early next week.
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi,

Just right after the 8.1.1 release has been published we’ve discovered a
serious bug in BasicAuthentication which affect all released versions of
Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found in
SOLR-13510.

I’m volunteering to do this release, if there are no objections, and I’d
like to create a RC early next week.

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Đạt Cao Mạnh]

+1 Looks good to me.

On Mon, Jun 3, 2019 at 2:19 PM Joel Bernstein  wrote:

> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, Jun 3, 2019 at 8:54 AM Cassandra Targett 
> wrote:
>
>> Jan, would you please suggest exact wording to correct the error you
>> pointed out (quoted below). Since I clearly don’t understand the change,
>> and this is months delayed already, that is likely be the fastest option to
>> get a respin started this week. Otherwise, it will need to wait for me to
>> wade back into the topic to see if I can understand what the correct
>> wording should be.
>>
>> Thank you,
>> Cassandra
>> On May 31, 2019, 3:37 PM -0500, Jan Høydahl ,
>> wrote:
>>
>> Viewed on a smartphone :)
>>
>> Comments:
>>
>> Major changes section:
>>
>> The Basic Authentication plugin now has an option forwardCredentials to
>> prevent Basic Auth headers from being sent for inter-node requests.
>>
>>
>> This is wrong. Basic Auth never sent basicauth headers inter-node, and
>> adding the “forwardcredentials” option lets user-originated requests be
>> forwarded with original basicauth credentials instead of PKI.
>>
>>
>>
>>
>>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Đạt Cao Mạnh]

Welcome Michael!

On Mon, 13 May 2019 at 22:10, David Smiley  wrote:

> Congratulations and welcome Mike!  Well deserved.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>
>> Hello everyone,
>>
>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>
>> Many of you probably know Mike as he's been around for quite a while
>> -- answering questions, reviewing patches, providing insight and
>> actively working on new code.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio, Mike.
>>
>> Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: [VOTE] Release Lucene/Solr 8.1.0 RC1

[Đạt Cao Mạnh]

Hi Ishan,

Should we respin the release for SOLR-13449.

On Wed, 8 May 2019 at 17:45, Kevin Risden  wrote:

> +1 SUCCESS! [1:15:45.039228]
>
> Kevin Risden
>
>
> On Wed, May 8, 2019 at 11:12 AM David Smiley 
> wrote:
>
>> +1
>> SUCCESS! [1:29:43.016321]
>>
>> Thanks for doing the release Ishan!
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Tue, May 7, 2019 at 1:49 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Please vote for release candidate 1 for Lucene/Solr 8.1.0
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC1-reve5839fb416083fcdaeedfb1e329a9fdaa29fdc50
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC1-reve5839fb416083fcdaeedfb1e329a9fdaa29fdc50
>>>
>>> Here's my +1
>>> SUCCESS! [0:46:38.948020]
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Fwd: Lucene/Solr 8.0

[Đạt Cao Mạnh]

gt; >
> > >> >
> > >> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > >> >
> > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler 
> wrote:
> > >> >
> > >> >
> > >> > Cool,
> > >> >
> > >> > I am working on giving my best release time guess as possible on
> the FOSDEM conference!
> > >> >
> > >> > Uwe
> > >> >
> > >> > -
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: u...@thetaphi.de
> > >> >
> > >> > -Original Message-
> > >> > From: Adrien Grand 
> > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >> > To: Lucene Dev 
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
> 4th.
> > >> >
> > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.feren...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >
> > >> > Hi,
> > >> > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> > >> >
> > >> > already created so we can start the process anytime now. Unless
> there are
> > >> > objections I'd like to start the feature freeze next week in order
> to build the
> > >> > first candidate the week after.
> > >> >
> > >> > We'll also need a 7.7 release but I think we can handle both with
> Alan so
> > >> >
> > >> > the question now is whether we are ok to start the release process
> or if there
> > >> > are any blockers left ;).
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward 
> > >> >
> > >> > a écrit :
> > >> >
> > >> >
> > >> > I’ve started to work through the various deprecations on the new
> master
> > >> >
> > >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> > >> > several of them, as it’s not entirely clear what to do.
> > >> >
> > >> >
> > >> > I’ll open two overarching issues in JIRA, one for lucene and one
> for Solr,
> > >> >
> > >> > with lists of the deprecations that need to be removed in each
> one.  I’ll create
> > >> > a shared branch on gitbox to work against, and push the changes
> I’ve already
> > >> > done there.  We can then create individual JIRA issues for any
> changes that
> > >> > are more involved than just deleting code.
> > >> >
> > >> >
> > >> > All assistance gratefully received, particularly for the Solr
> deprecations
> > >> >
> > >> > where there’s a lot of code I’m unfamiliar with.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:21, Alan Woodward 
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > I think the current plan is to do a 7.7 release at the same time as
> 8.0, to
> > >> >
> > >> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > >> > for now.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:10, Uwe Schindler  wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I will start and add the branch_8x jobs to Jenkins once I have some
> time
> > >> >
> > >> > later today.
> > >> >
> > >> >
> > >> > The question: How to proceed with branch_7x? Should we stop using it
> > >> >
> > >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> > >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
> would keep
> > >> > the jenkins jobs enabled for a while.
> > >> >
> > >> >
> > >> > Uwe
> > >> >
> > >> > -
> > >> > Uwe Schindler
> > >> 

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Đạt Cao Mạnh]

Welcome and congrats Tomoko!

On Tue, Apr 9, 2019 at 7:11 AM Karl Wright  wrote:

> Welcome!
> Karl
>
> On Mon, Apr 8, 2019 at 8:28 PM Christian Moen  wrote:
>
>> Congratulations, Tomoko-san!
>>
>> On Tue, Apr 9, 2019 at 12:20 AM Uwe Schindler  wrote:
>>
>>> Hi all,
>>>
>>> Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr
>>> committer!
>>>
>>> She has been working on
>>> https://issues.apache.org/jira/browse/LUCENE-2562 for several years
>>> with awesome progress and finally we got the fantastic Luke as a branch on
>>> ASF JIRA:
>>> https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
>>> Looking forward to the first release of Apache Lucene 8.1 with Luke
>>> bundled in the distribution. I will take care of merging it to master and
>>> 8.x branches together with her once she got the ASF account.
>>>
>>> Tomoko also helped with the Japanese and Korean Analyzers.
>>>
>>> Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to
>>> introduce yourself with a brief bio.
>>>
>>> Uwe & Robert (who nominated Tomoko)
>>>
>>> -
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

Cool Diego,

I will take a look on this. Thanks a lot!

Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Đạt Cao Mạnh]

For clarification:
>
> But this does not disable the HTTP/2 listener, it just makes SolrJ no
> longer use the Http2SolrClient and fall back to the old one.

This is true and it is not a bug. The reason here is for rolling updates,
since -Dsolr.http1=true nodes can *send* and *accept *requests *to/from*
Solr 7.x and Solr 8 without that flag. As I mentioned in CHANGES.txt for
rolling updates
Step 1. Some nodes wil be upgraded to Solr 8 with -Dsolr.http1=true, the
rest will still remain on Solr 7.x. They can communicate to each others
since only HTTP/1 is used
Step 2. All nodes get upgraded to Solr 8 with -Dsolr.http1=true.
Step 3. Some nodes with -Dsolr.http1=true (A) and the rest (B) without that
flag. A will talk with B using HTTP/1 (possible) and B will talk with A
using HTTP/2 (since HTTP/2 listener is enabled in -Dsolr.http1=true nodes)
Step 4: All nodes get upgraded to Solr 8 without solr.http1 flag. They will
talk with each other using HTTP/2 now.

On Thu, Mar 7, 2019 at 4:32 PM Uwe Schindler  wrote:

> Thanks for the reminder,
>
>
>
> I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the
> startup script. But this does not disable the HTTP/2 listener, it just
> makes SolrJ no longer use the Http2SolrClient and fall back to the old one.
> But that only affects the “new” solr servers as a “client” to old servers
> during rolling upgrade.
>
>
>
> I did a quick check, if the parameter makes its way to solr: yes, after
> starting solr with “-Dsolr.http1=true”:
>
> C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true
>
> … it showed the parameter in admin UI under system properties.
>
>
>
> But I did not test a full cluster in the short time. The HTTP/2 endpoint
> of the started server was still available, but outgoing solr requests
> should only go with HTTP1 then. I am sure somebody tested this in Linux,
> Windows is same as the system property reached the JVM, so startup scripts
> handle it right.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Alan Woodward 
> *Sent:* Thursday, March 7, 2019 9:17 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> Is there a way of passing Jetty parameters from the command line?  IOW,
> can Windows users do a rolling upgrade if they run ./solr restart
> -Djetty.module=http or whatever?
>
>
>
> On 6 Mar 2019, at 21:57, Uwe Schindler  wrote:
>
>
>
> I opened a blocker issue:
>
> https://issues.apache.org/jira/browse/SOLR-13299
>
>
>
> The fix is easy, will commit it soon to all 3 branches.
>
>
>
> IMHO, we should respin as non-working startup script on Windows for users
> of secured Solr servers is a blocker.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler 
> *Sent:* Wednesday, March 6, 2019 8:52 PM
> *To:* dev@lucene.apache.org
> *Subject:* RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> It looks like on Linux the Solr start script correctly sets module in
> jetty, so it disables http2 on Java 8. I have not tested this but it looks
> like on Windows the if statement is missing.
>
> If we cannot fix this soon we may release a Bugfix Version later, but this
> would prevent Windows users from upgrading.
>
> So I switch to +/-0 to release. What do others think?
>
> I will try to fix startup script later, maybe it's easy.
>
> Uwe
>
> Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler :
>
> Hi,
>
>
>
> I also checked the RC2. First automated smoke testing with Policeman
> Jenkins resulted in a +1 from Policeman Jenkins:
>
>
>
> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console
>
> SUCCESS! [2:42:28.295475]
>
>
>
> The testing was done with Java 8 and Java 9 (this is why it took longer).
>
>
>
> I also checked Changes.txt, looks fine (there is only a few typos in the
> changes about the switch of Solr to HTTP/2, but that’s not horrible, but we
> should improve it, as its one significant change): latter -> later
>
>
>
> I also checked the ZIP files of Lucene and Solr. Lucene looks as usual,
> MIGRATE.txt is also fine – thanks for adding recent information! JAR files
> also look fine, compiled with correct version of Java and patches
> multi-release class files are there.
>
>
>
> Apache Solr was unzipped and quickly tested on Windows: Startup with Java
> 8 and Java 11 worked without any problems from a directory with whitespace
> in path. I was able to do a HTTP/2 request with CURL (non-TLS) on both O/S:
>
>
>
> *Uwe Schindler@VEGA:*~ > curl -I --http2 localhost:8983/solr/
>
> HTTP/1.1 101 Switching Protocols
>
>
>
> HTTP/2 200
>
> x-frame-options: DENY
>
> content-type: text/html;charset=utf-8
>
> content-length: 14662
>
>
>
> So, it worked. In the webbrowser it did not use HTTP/2, as browsers
> require SSL for that (by default).
>
>
>
> Next I enabled TLS support by 

Re: Welcome Ignacio Vera to the PMC

[Đạt Cao Mạnh]

Congrats Ignacio!

On Mon, Mar 4, 2019 at 2:09 PM jim ferenczi  wrote:

> Welcome and congrats Ignacio!
>
> Le lun. 4 mars 2019 à 15:03, David Smiley  a
> écrit :
>
>> Welcome Ignacio!
>>
>> On Mon, Mar 4, 2019 at 7:53 AM Jason Gerlowski 
>> wrote:
>>
>>> Congrats Ignacio!
>>>
>>> On Mon, Mar 4, 2019 at 7:17 AM Martin Gainty 
>>> wrote:
>>> >
>>> > ¡Bienvenidos Ignacio!
>>> >
>>> > 
>>> > From: Dawid Weiss 
>>> > Sent: Monday, March 4, 2019 6:45 AM
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: Welcome Ignacio Vera to the PMC
>>> >
>>> > Welcome, Ignacio!
>>> >
>>> > On Mon, Mar 4, 2019 at 10:09 AM Adrien Grand 
>>> wrote:
>>> > >
>>> > > I am pleased to announce that Ignacio Vera has accepted the PMC's
>>> > > invitation to join.
>>> > >
>>> > > Welcome Ignacio!
>>> > >
>>> > > --
>>> > > Adrien
>>> > >
>>> > > -
>>> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> > >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Welcome Jason Gerlowski to the PMC

[Đạt Cao Mạnh]

Welcome, Jason!

On Fri, 22 Feb 2019 at 15:28, Adrien Grand  wrote:

> Welcome, Jason!
>
> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl  wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: HTTP/2 support completely missing in CHANGES.txt

[Đạt Cao Mạnh]

Hi Uwe,

All announement in solr/CHANGES.txt were removed in a merge, I added them
back. Please kindly review them.

Thanks!

On Thu, Jan 17, 2019 at 1:51 PM Uwe Schindler  wrote:

> Hi,
>
> I just reviewed the Lucene/Solr 8 changes text (in preparation to my
> FOSDEM talk) and figured out that there is no announcement about the
> recently added support for HTTP/2 in the Solr inter-node communication and
> inside the SolrJ client. We should really add some announement in the "new
> features". We should also give a statement that HTTPS support in
> combination with HTTP/2 only works with Java 9 or later.
>
> Who wants to add this?
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Congratulations to the new Lucene/Solr PMC chair, Cassandra Targett

[Đạt Cao Mạnh]

Congratulations, Cassandra!

On Wed, Jan 2, 2019 at 4:37 AM Michael McCandless 
wrote:

> Congrats  Cassandra!!
>
> Mike
>
> On Mon, Dec 31, 2018 at 5:32 PM Karl Wright  wrote:
>
>> Congratulations!
>>
>>
>> On Mon, Dec 31, 2018 at 5:20 PM Michael Sokolov 
>> wrote:
>>
>>> Heavy is the head that wears the crown - congrats and thank you! And
>>> here's to a peaceful transition of power in the new year :)
>>>
>>> On Mon, Dec 31, 2018 at 1:39 PM Dawid Weiss 
>>> wrote:
>>> >
>>> > Congratulations, Cassandra!
>>> >
>>> > On Mon, Dec 31, 2018 at 7:04 PM Gus Heck  wrote:
>>> > >
>>> > > Congratulations :)
>>> > >
>>> > > On Mon, Dec 31, 2018, 12:48 PM Alexandre Rafalovitch <
>>> arafa...@gmail.com wrote:
>>> > >>
>>> > >> Congratulations.
>>> > >>
>>> > >> Regards,
>>> > >>Alex
>>> > >>
>>> > >> On Mon, 31 Dec 2018 at 11:31, David Smiley <
>>> david.w.smi...@gmail.com> wrote:
>>> > >> >
>>> > >> > Congrats Cassandra!
>>> > >> >
>>> > >> > On Mon, Dec 31, 2018 at 11:28 AM Erick Erickson <
>>> erickerick...@gmail.com> wrote:
>>> > >> >>
>>> > >> >> Congrats Cassandra1
>>> > >> >>
>>> > >> >> On Sun, Dec 30, 2018 at 11:38 PM Adrien Grand 
>>> wrote:
>>> > >> >> >
>>> > >> >> > Every year, the Lucene PMC rotates the Lucene PMC chair and
>>> Apache
>>> > >> >> > Vice President position.
>>> > >> >> >
>>> > >> >> > This year we have nominated and elected Cassandra Targett as
>>> the
>>> > >> >> > chair, a decision that the board approved in its December 2018
>>> > >> >> > meeting.
>>> > >> >> >
>>> > >> >> > Congratulations, Cassandra!
>>> > >> >> >
>>> > >> >> > --
>>> > >> >> > Adrien
>>> > >> >> >
>>> > >> >> >
>>> -
>>> > >> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > >> >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> > >> >> >
>>> > >> >>
>>> > >> >>
>>> -
>>> > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> > >> >>
>>> > >> > --
>>> > >> > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> > >> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>> > >>
>>> > >>
>>> -
>>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> > >>
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
> Mike McCandless
>
> http://blog.mikemccandless.com
>


-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi David,

The whole solr cluster must be consistent on what protocol they are going
to use (on Java 8):
- If all nodes start with HTTP/2 without TLS they will talk with each
others using h2c
- If all nodes start with HTTP/1.1 with TLS, they will talk with each
others using https.

On Sun, Dec 2, 2018 at 7:31 PM David Smiley 
wrote:

> To be more clear: will SolrCloud inter-node communication in Java 8 be
> Http2 (unencrypted) by default or will the user have to do something to let
> Solr do this? E.g. will our SolrCloud tests in Java 8 be doing this mostly?
> On Sun, Dec 2, 2018 at 2:24 PM Đạt Cao Mạnh 
> wrote:
>
>> Hi,
>>
>> HTTP2 *without* TLS is possible. That mode is called h2c. (
>> https://http2.github.io/http2-spec/)
>>
>> On Sun, Dec 2, 2018 at 5:32 PM Uwe Schindler  wrote:
>>
>>> It's inofficially allowed to have that.  So yes, it works, if the
>>> client does it.
>>>
>>> Uwe
>>>
>>> Am December 2, 2018 5:28:30 PM UTC schrieb David Smiley <
>>> david.w.smi...@gmail.com>:
>>>>
>>>> > | So I think the best idea is to only support Java 9+, if you want
>>>> HTTP2 and TLS.
>>>>
>>>> +1
>>>>
>>>> Question: With Java 8 can we have HTTP2 *without* TLS?  I recall HTTP2
>>>> was strongly tying itself to encryption although it was technically
>>>> possible to have plaintext.
>>>>
>>>> On Sun, Dec 2, 2018 at 11:29 AM Đạt Cao Mạnh 
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> | So I think the best idea is to only support Java 9+, if you want
>>>>> HTTP2 and TLS.
>>>>> +1 for this
>>>>>
>>>>> I think the support for Java 8 + SSL + HTTP/2 by using Conscrypt or
>>>>> other methods can be done later, it is not necessary for merging http2
>>>>> branch to master.
>>>>>
>>>> --
>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>> http://www.solrenterprisesearchserver.com
>>>>
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+28357+Bremen=gmail=g>
>>> https://www.thetaphi.de
>>>
>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>>
>>
>> *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
>> *
>>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>


-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi,

HTTP2 *without* TLS is possible. That mode is called h2c. (
https://http2.github.io/http2-spec/)

On Sun, Dec 2, 2018 at 5:32 PM Uwe Schindler  wrote:

> It's inofficially allowed to have that.  So yes, it works, if the client
> does it.
>
> Uwe
>
> Am December 2, 2018 5:28:30 PM UTC schrieb David Smiley <
> david.w.smi...@gmail.com>:
>>
>> > | So I think the best idea is to only support Java 9+, if you want
>> HTTP2 and TLS.
>>
>> +1
>>
>> Question: With Java 8 can we have HTTP2 *without* TLS?  I recall HTTP2
>> was strongly tying itself to encryption although it was technically
>> possible to have plaintext.
>>
>> On Sun, Dec 2, 2018 at 11:29 AM Đạt Cao Mạnh 
>> wrote:
>>
>>> Hi guys,
>>>
>>> | So I think the best idea is to only support Java 9+, if you want HTTP2
>>> and TLS.
>>> +1 for this
>>>
>>> I think the support for Java 8 + SSL + HTTP/2 by using Conscrypt or
>>> other methods can be done later, it is not necessary for merging http2
>>> branch to master.
>>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>


-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi guys,

| So I think the best idea is to only support Java 9+, if you want HTTP2
and TLS.
+1 for this

I think the support for Java 8 + SSL + HTTP/2 by using Conscrypt or other
methods can be done later, it is not necessary for merging http2 branch to
master.

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi Uwe,

To enable Conscrypt we have include several related Jetty libraries, the
same thing will need to be done if we uses Java 9 ALPN. So support both
security providers and testing them is kinda painful in my point of view.


On Wed, Nov 28, 2018 at 4:16 PM Đạt Cao Mạnh 
wrote:

> Hi folks, Uwe
>
> After upgrading to Conscrypt 1.4.1. I still failure on
> https://jenkins.thetaphi.de/job/Lucene-Solr-http2-Linux/7/consoleText. I
> kinda feel that this SSL is big pain but can be solved easily in Java 9.
> Should it is possible for us to not supporting SSL in HTTP2 (anyone want to
> run SSL can use any HTTP2 proxy like nginx as a gate keeper).
>
> Thanks!
>
> On Wed, Nov 28, 2018 at 10:55 AM Uwe Schindler  wrote:
>
>> Hi,
>>
>>
>>
>> About the bundling of conscrypt.jar in the binary distribution of Apache
>> Solr, I opened LEGAL-425:
>>
>> https://issues.apache.org/jira/browse/LEGAL-425
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Uwe Schindler 
>> *Sent:* Wednesday, November 28, 2018 11:38 AM
>> *To:* dev@lucene.apache.org
>> *Subject:* RE: Poll: Merge jira/http2 to master branch
>>
>>
>>
>> Hi Dat, hi Shawn,
>>
>>
>>
>> Thanks for the confirmation! This is what I had in mind (missing ALPN
>> support).
>>
>>
>>
>> IMHO, we should not yet switch away from Java 8 as minimum requirement.
>> With multi-release JARs we are at the moment perfectly able to handle users
>> with newer Java versions, but we should still support Java 8 (as its still
>> widely deployed), although EOL is close. As Redhat, AdoptOpenJDK, and
>> several Linux distributions still provide support for Java 8 at least for 2
>> or 3 more years, I think it’s to early to switch. With recent changes, the
>> support by Oracle is no longer the way to go, as there are many
>> alternatives.
>>
>>
>>
>> My proposal would be to wait until master is branched to “branch_8x”
>> (stays on Java 8 + MR-JAR support), then change “master” to have Java 11 as
>> minimum requirement.
>>
>>
>>
>> About HTTP2: I have no problem with bundling conscrypt (is it needed for
>> both Jetty Server and Jetty Client)?, but disable it by default and only
>> register it in the Java TLS SPI, if Java 8 is used. On Java 9 and later use
>> the shipped HTTP2 support. My proposal would be to do it with a
>> Multirelease JAR (this is currently enabled in Lucene already).
>>
>>
>>
>> If there are license problems, we can do the following: Disable HTTP2 on
>> Java 8 completely but provide documentation in the Solr Ref Guide how to
>> enable it (something like: download conscrypt-uber.jar from maven and save
>> in solr/lib directory). We can enable it automatically, if class.forName()
>> does not throw CNFE). Maybe add a sysprop, but that’s not needed. I think
>> enabling conscrypt is easy with reflection only, or do we need to compile
>> hard against it. From what I figured out, it’s only used at a few places.
>>
>>
>>
>> SolrJ should by default ship without conscyrpt (make it “optional” maven
>> dependency). If it’s in classpath, enable it.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Đạt Cao Mạnh 
>> *Sent:* Wednesday, November 28, 2018 11:01 AM
>> *To:* Solr/Lucene Dev 
>> *Subject:* Re: Poll: Merge jira/http2 to master branch
>>
>>
>>
>> Hi,
>>
>>
>>
>> I will try to summary all the options here
>>
>> 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must
>> stick with HTTP/1.1
>>
>> 2. Set Java requirement to 9 and use ALPN implementation of JDK 9
>>
>> 3. If users want to use HTTP/2, we will notice about license problem then
>> download and use Conscrypt library. Of course that we still test the
>> Conscrypt implementation in tests.
>>
>>
>>
>>
>>
>> On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey  wrote:
>>
>> On 11/27/2018 3:32 AM, Uwe Schindler wrote:
>> > I'd like to bring one thing into attention: This library conscrypt is
>> ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork
>>

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi folks, Uwe

After upgrading to Conscrypt 1.4.1. I still failure on
https://jenkins.thetaphi.de/job/Lucene-Solr-http2-Linux/7/consoleText. I
kinda feel that this SSL is big pain but can be solved easily in Java 9.
Should it is possible for us to not supporting SSL in HTTP2 (anyone want to
run SSL can use any HTTP2 proxy like nginx as a gate keeper).

Thanks!

On Wed, Nov 28, 2018 at 10:55 AM Uwe Schindler  wrote:

> Hi,
>
>
>
> About the bundling of conscrypt.jar in the binary distribution of Apache
> Solr, I opened LEGAL-425:
>
> https://issues.apache.org/jira/browse/LEGAL-425
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler 
> *Sent:* Wednesday, November 28, 2018 11:38 AM
> *To:* dev@lucene.apache.org
> *Subject:* RE: Poll: Merge jira/http2 to master branch
>
>
>
> Hi Dat, hi Shawn,
>
>
>
> Thanks for the confirmation! This is what I had in mind (missing ALPN
> support).
>
>
>
> IMHO, we should not yet switch away from Java 8 as minimum requirement.
> With multi-release JARs we are at the moment perfectly able to handle users
> with newer Java versions, but we should still support Java 8 (as its still
> widely deployed), although EOL is close. As Redhat, AdoptOpenJDK, and
> several Linux distributions still provide support for Java 8 at least for 2
> or 3 more years, I think it’s to early to switch. With recent changes, the
> support by Oracle is no longer the way to go, as there are many
> alternatives.
>
>
>
> My proposal would be to wait until master is branched to “branch_8x”
> (stays on Java 8 + MR-JAR support), then change “master” to have Java 11 as
> minimum requirement.
>
>
>
> About HTTP2: I have no problem with bundling conscrypt (is it needed for
> both Jetty Server and Jetty Client)?, but disable it by default and only
> register it in the Java TLS SPI, if Java 8 is used. On Java 9 and later use
> the shipped HTTP2 support. My proposal would be to do it with a
> Multirelease JAR (this is currently enabled in Lucene already).
>
>
>
> If there are license problems, we can do the following: Disable HTTP2 on
> Java 8 completely but provide documentation in the Solr Ref Guide how to
> enable it (something like: download conscrypt-uber.jar from maven and save
> in solr/lib directory). We can enable it automatically, if class.forName()
> does not throw CNFE). Maybe add a sysprop, but that’s not needed. I think
> enabling conscrypt is easy with reflection only, or do we need to compile
> hard against it. From what I figured out, it’s only used at a few places.
>
>
>
> SolrJ should by default ship without conscyrpt (make it “optional” maven
> dependency). If it’s in classpath, enable it.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Đạt Cao Mạnh 
> *Sent:* Wednesday, November 28, 2018 11:01 AM
> *To:* Solr/Lucene Dev 
> *Subject:* Re: Poll: Merge jira/http2 to master branch
>
>
>
> Hi,
>
>
>
> I will try to summary all the options here
>
> 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must
> stick with HTTP/1.1
>
> 2. Set Java requirement to 9 and use ALPN implementation of JDK 9
>
> 3. If users want to use HTTP/2, we will notice about license problem then
> download and use Conscrypt library. Of course that we still test the
> Conscrypt implementation in tests.
>
>
>
>
>
> On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey  wrote:
>
> On 11/27/2018 3:32 AM, Uwe Schindler wrote:
> > I'd like to bring one thing into attention: This library conscrypt is
> ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork
> named BoringSSL. I'd recommend to check the licensing, because OpenSSL
> licenses are a bit strange (some BSD fork, also ASF2, but some code is
> still outdated - I am not sure what the fork actually uses). I have the
> feeling we should include ASF legal department.
> >
> > Nevertheless, I am not 100% sure if conscrypt should really be inclued
> by default in SolrJ. As SolrJ is a client library for Solr and can be used
> by external projects, there is the problem of incompatibilities with the
> native C code included. E.g., if one uses SolrJ with IBM J9 or other Java
> versions different from openjdk. So I'd be careful. My question is: Do we
> really need that library. To me it looks like it improves speed only, or is
> there something that requires its use?
>
> As you might know ... full and proper htt

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi,

I will try to summary all the options here
1. No support for HTTP/2 + SSL at all, if users want to run SSL they must
stick with HTTP/1.1
2. Set Java requirement to 9 and use ALPN implementation of JDK 9
3. If users want to use HTTP/2, we will notice about license problem then
download and use Conscrypt library. Of course that we still test the
Conscrypt implementation in tests.


On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey  wrote:

> On 11/27/2018 3:32 AM, Uwe Schindler wrote:
> > I'd like to bring one thing into attention: This library conscrypt is
> ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork
> named BoringSSL. I'd recommend to check the licensing, because OpenSSL
> licenses are a bit strange (some BSD fork, also ASF2, but some code is
> still outdated - I am not sure what the fork actually uses). I have the
> feeling we should include ASF legal department.
> >
> > Nevertheless, I am not 100% sure if conscrypt should really be inclued
> by default in SolrJ. As SolrJ is a client library for Solr and can be used
> by external projects, there is the problem of incompatibilities with the
> native C code included. E.g., if one uses SolrJ with IBM J9 or other Java
> versions different from openjdk. So I'd be careful. My question is: Do we
> really need that library. To me it looks like it improves speed only, or is
> there something that requires its use?
>
> As you might know ... full and proper http/2 support with Java 8
> requires the conscrypt library.  With Java 9 or higher, the
> functionality is provided natively by Java.  If I remember right, what
> conscrypt provides that Java 8 lacks is ALPN.
>
> If there are license issues with conscrypt, perhaps it might make sense
> to require a newer major version of Java instead ... but I think that
> upgrading the project's Java requirement to 9, 10, or 11 probably
> requires a wider discussion.  Lucene probably has no burning need for it
> right now.  I have no idea whether there are language features in Java
> 9+ that we as a group are wanting to use.  Another point for
> consideration is that the effective EOL for Java 8 is fast approaching,
> and EOL dates have already come and gone for 9 and 10.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi Uwe,

It seems that is conflict between settings default security provider of
conscrypt and httpclient. I will try to resolve that problem today.

Thanks!

On Tue, Nov 27, 2018 at 9:11 AM Simon Willnauer 
wrote:

> folks,
>
> I just want to ask if this is an issue or not but this branch is
> associated with a blocker issue for 8.0. If it doesn't have an owner
> or is actively worked on do we still consider it a blocker? I mean
> don't get me wrong but if this is something that we don't dedicate
> time and committer to I think we should re-think the decision if this
> is a blocker or not?
>
> simon
>
> On Tue, Nov 27, 2018 at 9:03 AM Uwe Schindler  wrote:
> >
> > Ah I figured out, there is an issue open already:
> > https://github.com/google/conscrypt/issues/560
> >
> > Seems to be closed, so we have to wait for a new release, right?
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 8:48 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > It seems to work with Java 9/10/11, but with Java 8 almost all Solr
> tests fail.
> > > Reason is a mising JAR library: conscrypt.jar (which seems to be used
> by Jetty
> > > to support some HTTP/2 requires stuff not included in the JDK).
> > >
> > > We should at least disable HTTP/2 in Java 8 or add this library (seems
> to
> > > contain native code): https://github.com/google/conscrypt#uber-jar
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > OK,
> > > >
> > > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos,
> Solaris). On
> > > > ASF Jenkins I created the standard "tests" job for now, others can
> be added
> > > > later. They are called "http2" at the place of the version (instead
> of "7.x",
> > > > "7.6", "master").
> > > >
> > > > Let's see how it behaves,
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Uwe Schindler 
> > > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > > >
> > > > > Uwe
> > > > >
> > > > > -
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > http://www.thetaphi.de
> > > > > eMail: u...@thetaphi.de
> > > > >
> > > > > > -Original Message-
> > > > > > From: Chris Hostetter 
> > > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > > To: dev@lucene.apache.org
> > > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > > >
> > > > > >
> > > > > > : The job would use the usual randomization anyways, so what's
> your
> > > > > > : special request? So we should see an improvement asap.
> > > > > >
> > > > > > No special request beyond asking you to setup a job on your
> personal
> > > > > > jenkins server -- just pointing out that i tried asking you for
> this via
> > > > > > jira ping 2 weeks ago :)
> > > > > >
> > > > > > And yes: if my experimentation is correct, we should see a much
> lower
> > > > rate
> > > > > > of failures from your box when testing Dat's http2 branch with
> java>9 vs
> > > > > > what we see w/master & 7x
> > > > > >
> > > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch
> and not yet
> > > > > > : >
> > > > > > : > Uwe: note that in particular it would be really helpful to
> have a
> > > > > > : > jira/http2 jenkins job setup on your policeman's jenkins
> box, where
> > > > > java11
> > > > > > : > and java12 are randomized, since you seem to hit the java>9
> SSL
> > > > related
> > > > > > : > bugs the most, and AFAICT those problems are fixed on the
> > > jira/http2
> > > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > > > >
> > > > > >
> > > > > > -Hoss
> > > > > > http://www.lucidworks.com/
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > > 

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi Uwe,

That would be nice if we have a public Jenkins report that everyone can
look. Because of this change gonna be a blocker for the release of 8.0, so
it is worth to notice to all people about any failures of the branch.

Thanks!


On Mon, Nov 26, 2018 at 2:30 PM Uwe Schindler  wrote:

> I agree with Simon,
>
>
>
> I’d prefer to just add jenkins jobs for the “http2” branch and not yet
> merge it. That’s possible to setup in short time. If the number of failures
> don’t grow beyond the current state, we can merge. If it get’s worse on
> same hardware, then we should not merge yet.
>
>
>
> The problem with Solr tests is that the reliability differs from hardware
> to hardware (because of some timing/multithreading issues). So to make a
> comparison, you should compare with and without patch on same hardware.
>
>
>
> I can setup a jenkins job on ASF jenkins and Policeman jenkins (copy of
> master job with different branch) and let it run. I can configure the dev
> mailing list or Cao Mạnh Đạt’s mail address there. What do you prefer?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Simon Willnauer 
> *Sent:* Monday, November 26, 2018 3:03 PM
> *To:* Lucene/Solr dev 
> *Subject:* Re: Poll: Merge jira/http2 to master branch
>
>
>
> I don't know what the state of the tests is for solr. I'm also not on top
> of your work so please correct me if I am wrong. You are saying you won't
> have enough time for the feature in the near future but you want to merge
> it still to master so others can chime in? I don't think this is an
> approach that works. I think if others need to chime in it should be done
> on the branch? My definition for being ready to be merged to master is that
> the code and tests are stable. If there are minor tasks to be done then I
> guess I am fine with that. To me this sounds like it will put a ton of work
> on somebody else plate? I mean mark is spending a lot of time on the tests
> and this would make his life even harder?
>
>
>
> I don't think we should do this.
>
>
>
> simon
>
>
>
> On Mon, Nov 26, 2018 at 12:08 PM Đạt Cao Mạnh 
> wrote:
>
> Hi guys,
>
>
>
> The changes in jira/http2 branch is very close to be commit now, but the
> current state of tests make me quite nervous about merging. I have a local
> Jenkins job for testing jira/http2 and the result is quite bad so far. I'm
> not sure failures caused by jira/http2 changes or the master branch. I wish
> I have more time on hardening and debugging the failures in jira/http2
> branch. *But the recent changes in my job do not allow me to spend as
> much time as I want.*
>
>
>
> Therefore I'm thinking about merging jira/http2 to the master branch now
> and with the support of the community we can make tests more reliable. (not
> just me watching and working on it).
>
> I know that Mark Miller is working on hardness tests, do you want me to
> wait for your work to be committed first?
>
>
>
> Thanks!
>
>
>
> --
>
> *Best regards,*
>
> *Cao Mạnh Đạt*
>
>
>
> *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
> *
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi guys,

The changes in jira/http2 branch is very close to be commit now, but the
current state of tests make me quite nervous about merging. I have a local
Jenkins job for testing jira/http2 and the result is quite bad so far. I'm
not sure failures caused by jira/http2 changes or the master branch. I wish
I have more time on hardening and debugging the failures in jira/http2
branch. *But the recent changes in my job do not allow me to spend as much
time as I want.*

Therefore I'm thinking about merging jira/http2 to the master branch now
and with the support of the community we can make tests more reliable. (not
just me watching and working on it).
I know that Mark Miller is working on hardness tests, do you want me to
wait for your work to be committed first?

Thanks!

-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Lucene/Solr 7.6

[Đạt Cao Mạnh]

Hi guys,

Is it ok for backporting SOLR-12969 to branch_7_6?

On Sat, Nov 10, 2018 at 3:50 PM Steve Rowe  wrote:

> Hi Cassandra,
>
> > On Nov 9, 2018, at 3:47 PM, Cassandra Targett 
> wrote:
> >
> > I don't know if it's on the Release ToDo list, but we need a Jenkins job
> for the Ref Guide to be built from branch_7x  also.
>
> I assume you mean a branch_7_6 ref guide job, since there already is one
> for branch_7x; I created it along with the others.
>
> FYI the ref guide job is listed among those to create on
> https://wiki.apache.org/lucene-java/JenkinsReleaseBuilds , which is
> linked from
> https://wiki.apache.org/lucene-java/ReleaseTodo#Jenkins_Release_Builds .
>
> Steve
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

Hi Uwe, yeah I think we should continue working on that branch, I will
do regularly make it up to date with master branch.

On Mon, Nov 5, 2018 at 3:44 PM Uwe Schindler  wrote:

> There is a branch already, this is why I mentioned "committing to branch":
>
> https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/gradle
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen=gmail=g>
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Erick Erickson 
> > Sent: Monday, November 5, 2018 4:27 PM
> > To: dev@lucene.apache.org
> > Subject: Re: Call for help: moving from ant build to gradle
> >
> > Seems more efficient to put it on a branch for easier collaboration.
> > On Mon, Nov 5, 2018 at 7:24 AM Michael McCandless
> >  wrote:
> > >
> > > +1 to put latest progress onto a branch and iterate.
> > >
> > > Those benefits of Gradle over Ant sound compelling.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > >
> > > On Mon, Nov 5, 2018 at 10:22 AM David Smiley
> >  wrote:
> > >>
> > >> Glad to see this Dat & Uwe!
> > >>
> > >> RE "Should we all commit to the branch for proceeding?"
> > >>
> > >> In this context do you mean are we "committed" to migrating to Gradle?
> > (+1 from me).  Or that future work should continue to use that branch?
> It
> > seems very logical to use a branch.
> > >>
> > >> ~ David
> > >>
> > >> On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler 
> > wrote:
> > >>>
> > >>> Hi Đạt,
> > >>>
> > >>>
> > >>>
> > >>> great work. I had some time to look into it, looks good as a start.
> I agree
> > there is a lot of work to be done, especially the additional tasks for
> > regenerating sources, extracting data from ICU, quality checks,
> > documentation (XSLT). Also the transcoder to Java 9+ for MR-JARs is still
> > missing as a “compile”-like task (I can help with that).
> > >>>
> > >>>
> > >>>
> > >>> Should we all commit to the branch for proceeding?
> > >>>
> > >>> Uwe
> > >>>
> > >>>
> > >>>
> > >>> -
> > >>>
> > >>> Uwe Schindler
> > >>>
> > >>> Achterdiek 19, D-28357 Bremen
> > >>>
> > >>> http://www.thetaphi.de
> > >>>
> > >>> eMail: u...@thetaphi.de
> > >>>
> > >>>
> > >>>
> > >>> From: Đạt Cao Mạnh 
> > >>> Sent: Sunday, November 4, 2018 8:13 PM
> > >>> To: Solr/Lucene Dev 
> > >>> Subject: Call for help: moving from ant build to gradle
> > >>>
> > >>>
> > >>>
> > >>> Hi guys,
> > >>>
> > >>>
> > >>>
> > >>> Recently, I had a chance of working on modifying different build.xml
> of
> > our project. To be honest that was a painful experience, especially the
> > number of steps for adding a new module in our project. We reach the
> > limitation point of Ant and moving to Gradle seems a good option since
> it has
> > been widely used in many projects. There are several benefits of the
> moving
> > here that I would like to mention
> > >>>
> > >>> * The capability of caching result in Gradle make running task much
> > faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> > (comparing to more than a minute of Ant).
> > >>>
> > >>> * Adding modules is much easier now.
> > >>>
> > >>> * Adding dependencies is a pleasure now since we don't have to run
> ant
> > clean-idea and ant idea all over again.
> > >>>
> > >>> * Natively supported by different IDEs.
> > >>>
> > >>>
> > >>>
> > >>> On my very boring long flight from Montreal back to Vietnam, I tried
> to
> > convert the Lucene/Solr Ant to Gradle, I finally achieved something here
> by
> > being able to import project and run tests natively from IntelliJ IDEA
> (branch
> > jira/gradle).
> > >>>
> > >>>
> > >>>
> > >>> I'm converting ant precommit for Lucene to Gradle. But there are a
> lot of
> > things need to be done here and my limitation understanding in our Ant
> > build and Gradle may make the work take a lot of time to finish.
> > >>>
> > >>>
> > >>>
> > >>> Therefore, I really need help from the community to finish the work
> and
> > we will be able to move to a totally new, modern, powerful build tool.
> > >>>
> > >>>
> > >>>
> > >>> Thanks!
> > >>>
> > >>>
> > >>
> > >> --
> > >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

Hi guys,

Recently, I had a chance of working on modifying different build.xml of our
project. To be honest that was a painful experience, especially the number
of steps for adding a new module in our project. We reach the limitation
point of Ant and moving to Gradle seems a good option since it has been
widely used in many projects. There are several benefits of the moving here
that I would like to mention
* The capability of caching result in Gradle make running task much faster.
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing
to more than a minute of Ant).
* Adding modules is much easier now.
* Adding dependencies is a pleasure now since we don't have to run ant
clean-idea and ant idea all over again.
* Natively supported by different IDEs.

On my very boring long flight from Montreal back to Vietnam, I tried to
convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
being able to import project and run tests natively from IntelliJ IDEA
(branch jira/gradle).

I'm converting ant precommit for Lucene to Gradle. But there are a lot of
things need to be done here and my limitation understanding in our Ant
build and Gradle may make the work take a lot of time to finish.

Therefore, I really need help from the community to finish the work and we
will be able to move to a totally new, modern, powerful build tool.

Thanks!

Re: Welcome Gus Heck as Lucene/Solr committer

[Đạt Cao Mạnh]

Welcome, Gus!

On Thu, Nov 1, 2018 at 2:54 PM Jan Høydahl  wrote:

> Welcome, Gus!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 1. nov. 2018 kl. 13:22 skrev David Smiley :
>
> Hi all,
>
> Please join me in welcoming Gus Heck as the latest Lucene/Solr committer!
>
> Congratulations and Welcome, Gus!
>
> Gus, it's traditional for you to introduce yourself with a brief bio.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh]

t;>>>
>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN
>>>>>
>>>>> As David mentioned, many of the SOlr committers are at Activate, which
>>>>> ends Thursday so feedback (and work) may be a bit delayed.
>>>>> On Wed, Oct 17, 2018 at 8:11 AM David Smiley 
>>>>> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > Thanks for volunteering to do the 8.0 release Jim!
>>>>> >
>>>>> > Many of us are at the Activate Conference in Montreal.  We had a
>>>>> committers meeting where we discussed some of the blockers.  I think only 
>>>>> a
>>>>> couple items were raised.  I'll leave Dat to discuss the one on HTTP2.  On
>>>>> the Solr nested docs front, I articulated one and we mostly came to a
>>>>> decision on how to do it.  It's not "hard" just a matter of how to hook in
>>>>> some functionality so that it's user-friendly.  I'll file an issue for
>>>>> this.  Inexplicably I'm sheepish about marking issues "blocker" but I
>>>>> shouldn't be.  I'll file that issue and look at another issue or two that
>>>>> ought to be blockers.  Nothing is "hard" or tons of work that is in my
>>>>> sphere of work.
>>>>> >
>>>>> > On the Lucene side, I will commit
>>>>> https://issues.apache.org/jira/browse/LUCENE-7875 RE MultiFields
>>>>> either late tonight or tomorrow when I have time.  It's ready to be
>>>>> committed; just sitting there.  It's a minor thing but important to make
>>>>> this change now before 8.0.
>>>>> >
>>>>> > I personally plan to spend more time on the upcoming weeks on a few
>>>>> of these 8.0 things.
>>>>> >
>>>>> > ~ David
>>>>> >
>>>>> >
>>>>> > On Wed, Oct 17, 2018 at 4:21 AM jim ferenczi 
>>>>> wrote:
>>>>> >>
>>>>> >> Hi,
>>>>> >> We still have two blockers for the Lucene 8 release:
>>>>> >>
>>>>> https://issues.apache.org/jira/browse/LUCENE-7075?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20
>>>>> >> We're planning to work on these issues in the coming days, are
>>>>> there any other blockers (not in the list) on Solr side.
>>>>> >> Now that Lucene 7.5 is released I'd like to create a Lucene 8
>>>>> branch soon (next week for instance ? ). There are some work to do to make
>>>>> sure that all tests pass, add the new version...
>>>>> >> I can take care of it if there are no objections. Creating the
>>>>> branch in advance would help to stabilize this version (people can 
>>>>> continue
>>>>> to work on new features that are not targeted for 8.0) and
>>>>> >> we can discuss the best date for the release when all blockers are
>>>>> resolved. What do you think ?
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Le mar. 18 sept. 2018 à 11:32, Adrien Grand  a
>>>>> écrit :
>>>>> >>>
>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 the
>>>>> right issue for HTTP/2 support? Should we make it a blocker for 8.0?
>>>>> >>>
>>>>> >>> Le lun. 3 sept. 2018 à 23:37, Adrien Grand  a
>>>>> écrit :
>>>>> >>>>
>>>>> >>>> For the record here is the JIRA query for blockers that Erick
>>>>> referred to:
>>>>> https://issues.apache.org/jira/browse/SOLR-12720?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20
>>>>> >>>>
>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi <
>>>>> jim.feren...@gmail.com> a écrit :
>>>>> >>>>>
>>>>> >>>>> Ok thanks Đạt and Erick. I'll follow the blockers on Jira.  Đạt
>>>>> do you have an issue opened for the HTTP/2 support ?
>>>>> >>>>>
>>>>> >&

Re: [DISCUSS] Moving from Ant build to Gradle

[Đạt Cao Mạnh]

Hi Ryan,

Do you have a wip patch? That will be helpful for others who want to
continue from your work. The current ant build have tons of tasks but we
may want to port several most important tasks.


On Thu, Oct 11, 2018 at 8:37 PM Ryan Ernst  wrote:

> There was an issue before (
> https://issues.apache.org/jira/browse/LUCENE-5755) that looked at
> switching to some other build system. A few were discussed, but at the time
> nobody had the time to do the work. I've investigated migrating to gradle a
> couple times in the past, but there is so much stuff in the ant build (and
> the shadow maven build) that migration becomes a lot of work to swtich
> everythin at once. The last time I looked, though, was about 1.5 years ago.
> It is something I would like to pick back up, but still do not have the
> time to invest personally.
>
> On Wed, Oct 10, 2018 at 3:53 PM Đạt Cao Mạnh 
> wrote:
>
>> Hi all,
>>
>> Recently I wanted to create another module in Solr to group all common
>> dependencies of Server and Solrj module. It seems that to do such kind of
>> thing is very painful, including hacks and adding support for different ide
>> and maven. Should we consider on moving to Gradle which seems better and
>> standard nowadays?
>>
>> Thanks!
>> Dat
>>
>

[DISCUSS] Moving from Ant build to Gradle

[Đạt Cao Mạnh]

Hi all,

Recently I wanted to create another module in Solr to group all common
dependencies of Server and Solrj module. It seems that to do such kind of
thing is very painful, including hacks and adding support for different ide
and maven. Should we consider on moving to Gradle which seems better and
standard nowadays?

Thanks!
Dat

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh]

Hi Jim,

I really want to introduce the support of HTTP/2 into Solr 8.0 (currently
cooked in jira/http2 branch). The changes of that branch are less than Star
Burst effort and closer to be merged into master branch.

Thanks!

On Fri, Aug 31, 2018 at 3:55 PM jim ferenczi  wrote:

> Hi all,
> I'd like to get some feedback regarding the upcoming Lucene/Solr 8
> release. There are still some cleanups and docs to add on the Lucene side
> but it seems that all blockers are resolved.
> From a Solr perspective are there any important changes that need to be
> done or are we still good with the October target for the release ? Adrien
> mentioned the Star Burst effort some time ago, is it something that is
> planned for 8 ?
>
> Cheers,
> Jim
>
> Le mer. 1 août 2018 à 19:02, David Smiley  a
> écrit :
>
>> Yes, that new BKD/Points based code is definitely something we want in 8
>> or 7.5 -- it's a big deal.  I think it would also be awesome if we had
>> highlighter that could use the Weight.matches() API -- again for either 7.5
>> or 8.  I'm working on this on the UnifiedHighlighter front and Alan from
>> other aspects.
>> ~ David
>>
>> On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand  wrote:
>>
>>> I was hoping that we would release some bits of this new support for geo
>>> shapes in 7.5 already. We are already very close to being able to index
>>> points, lines and polygons and query for intersection with an envelope. It
>>> would be nice to add support for other relations (eg. disjoint) and queries
>>> (eg. polygon) but the current work looks already useful to me.
>>>
>>> Le mer. 1 août 2018 à 17:00, Robert Muir  a écrit :
>>>
 My only other suggestion is we may want to get Nick's shape stuff into
 the sandbox module at least for 8.0 so that it can be tested out. I
 think it looks like that wouldn't delay any October target though?

 On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand  wrote:
 > I'd like to revive this thread now that these new optimizations for
 > collection of top docs are more usable and enabled by default in
 > IndexSearcher (https://issues.apache.org/jira/browse/LUCENE-8060).
 Any
 > feedback about starting to work towards releasing 8.0 and targeting
 October
 > 2018?
 >
 >
 > Le jeu. 21 juin 2018 à 09:31, Adrien Grand  a
 écrit :
 >>
 >> Hi Robert,
 >>
 >> I agree we need to make it more usable before 8.0. I would also like
 to
 >> improve ReqOptSumScorer (
 https://issues.apache.org/jira/browse/LUCENE-8204)
 >> to leverage impacts so that queries that incorporate queries on
 feature
 >> fields (https://issues.apache.org/jira/browse/LUCENE-8197) in an
 optional
 >> clause are also fast.
 >>
 >> Le jeu. 21 juin 2018 à 03:06, Robert Muir  a
 écrit :
 >>>
 >>> How can the end user actually use the biggest new feature: impacts
 and
 >>> BMW? As far as I can tell, the issue to actually implement the
 >>> necessary API changes (IndexSearcher/TopDocs/etc) is still open and
 >>> unresolved, although there are some interesting ideas on it. This
 >>> seems like a really big missing piece, without a proper API, the
 stuff
 >>> is not really usable. I also can't imagine a situation where the API
 >>> could be introduced in a followup minor release because it would be
 >>> too invasive.
 >>>
 >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand 
 wrote:
 >>> > Hi all,
 >>> >
 >>> > I would like to start discussing releasing Lucene/Solr 8.0.
 Lucene 8
 >>> > already
 >>> > has some good changes around scoring, notably cleanups to
 >>> > similarities[1][2][3], indexing of impacts[4], and an
 implementation of
 >>> > Block-Max WAND[5] which, once combined, allow to run queries
 faster
 >>> > when
 >>> > total hit counts are not requested.
 >>> >
 >>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
 >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
 >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
 >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
 >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
 >>> >
 >>> > In terms of bug fixes, there is also a bad relevancy bug[6] which
 is
 >>> > only in
 >>> > 8.0 because it required a breaking change[7] to be implemented.
 >>> >
 >>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
 >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
 >>> >
 >>> > As usual, doing a new major release will also help age out old
 codecs,
 >>> > which
 >>> > in-turn make maintenance easier: 8.0 will no longer need to care
 about
 >>> > the
 >>> > fact that some codecs were initially implemented with a
 random-access
 >>> > API
 >>> > for doc values, that pre-7.0 indices encoded norms differently,
 or that
 

Re: Welcome Nhat Nguyen as Lucene/Solr committer

[Đạt Cao Mạnh]

Welcome Nhat! Another Vietnamese guy!!
On Tue, Jun 19, 2018 at 6:12 AM Karl Wright  wrote:

> Welcome!!
> Karl
> On Mon, Jun 18, 2018 at 4:42 PM Adrien Grand  wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Nhat Nguyen as the latest Lucene/Solr
>> committer.
>> Nhat, it's tradition for you to introduce yourself with a brief bio.
>>
>> Congratulations and Welcome!
>>
>> Adrien
>>
>

Re: [VOTE] Release Lucene/Solr 7.3.1 RC2

[Đạt Cao Mạnh]

This vote has passed, thanks all for voting,

I’ll go start on next steps now.

On Sun, May 13, 2018 at 9:29 PM Tommaso Teofili <tommaso.teof...@gmail.com>
wrote:

> +1
>
> SUCCESS! [2:41:456007]
>
> Il giorno dom 13 mag 2018 alle ore 05:59 Ahmet Arslan
> <iori...@yahoo.com.invalid> ha scritto:
>
>> +1
>>
>> SUCCESS! [1:19:56.690027]
>>
>> Ahmet
>>
>>
>>
>>
>> On Saturday, May 12, 2018, 12:41:16 AM GMT+3, Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>
>>
>>
>>
>> +1
>>
>> SUCCESS! [0:40:57.887333]
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Fri, May 11, 2018 at 1:09 PM, Adrien Grand <jpou...@gmail.com> wrote:
>> > +1
>> > SUCCESS! [1:33:37.370199]
>> >
>> > Le mer. 9 mai 2018 à 16:59, Mark Miller <markrmil...@gmail.com> a
>> écrit :
>> >> Even before I saw that comment, I was thinking poor Alan...
>> >>
>> >> - Mark
>> >>
>> >>
>> >> On Wed, May 9, 2018 at 7:31 AM Alan Woodward <romseyg...@gmail.com>
>> wrote:
>> >>> +1
>> >>> SUCCESS! [3:10:43.862442]
>> >>>
>> >>> My internet has been really very slow today...
>> >>>
>> >>> On Wed, May 9, 2018 at 5:50 AM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
>> wrote:
>> >>>> Please vote for release candidate 2 for Lucene/Solr 7.3.1
>> >>>>
>> >>>> The artifact can be downloaded from:
>> >>>> https://dist.apache.org/repos/ dist/dev/lucene/lucene-solr-7.
>> 3.1-RC2- revae0705edb59eaa567fe13ed3a22 2fdadc7153680/
>> >>>>
>> >>>> You can run the smoke tester directly with this command:
>> >>>> python3 -u dev-tools/scripts/smokeTestRel ease.py
>> https://dist.apache. org/repos/dist/dev/lucene/ lucene-solr-7.3.1-RC2-
>> revae0705edb59eaa567fe13ed3a22 2fdadc7153680
>> >>>>
>> >>>> Here’s my +1
>> >>>> SUCCESS! [0:53:47.443795]
>> >>>>
>> >>>
>> >>>
>> >> --
>> >> - Mark
>> >> about.me/markrmiller
>> >>
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

[VOTE] Release Lucene/Solr 7.3.1 RC2

[Đạt Cao Mạnh]

Please vote for release candidate 2 for Lucene/Solr 7.3.1

The artifact can be downloaded from:
*https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC2-revae0705edb59eaa567fe13ed3a222fdadc7153680/
*

You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
*https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC2-revae0705edb59eaa567fe13ed3a222fdadc7153680
*

Here’s my +1
SUCCESS! [0:53:47.443795]

Re: [VOTE] Release Lucene/Solr 7.3.1 RC1

[Đạt Cao Mạnh]

This release needs to spin because of SOLR-12316.

On Thu, May 3, 2018 at 6:31 PM Ahmet Arslan <iori...@yahoo.com.invalid>
wrote:

> +1
>
> SUCCESS! [1:15:16.705804]
>
> Ahmet
>
>
> On Wednesday, May 2, 2018, 9:55:04 PM GMT+3, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
>
>
>
>
> +1
> SUCCESS! [1:04:51.914445]
>
> On Wed, May 2, 2018 at 12:32 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
> > +1
> >
> > SUCCESS! [0:49:04.927108]
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Wed, May 2, 2018 at 6:40 AM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
> wrote:
> >> Please vote for release candidate 1 for Lucene/Solr 7.3.1
> >>
> >> The artifacts can be downloaded from:
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a
> >>
> >> Here's my +1
> >> SUCCESS! [0:52:14.381028]
> >>
> >
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[VOTE] Release Lucene/Solr 7.3.1 RC1

[Đạt Cao Mạnh]

Please vote for release candidate 1 for Lucene/Solr 7.3.1

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a

Here's my +1
SUCCESS! [0:52:14.381028]

Re: BugFix release 7.3.1

[Đạt Cao Mạnh]

Hi Varun,

I think the log is fine, it seems to happen at the end of the test when ZK
was shut down.

On Wed, Apr 25, 2018 at 12:43 PM Varun Thacker <va...@vthacker.in> wrote:

> Thanks Dat! It's committed
>
> I was however not able to run the full tests successfully. I ran into
> thousands of these messages which seem to be fixed by
> https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=a4789db
> ? Although https://issues.apache.org/jira/browse/SOLR-12200 is still open.
>
>
>[junit4]   2> 1947362 ERROR
> (OverseerAutoScalingTriggerThread-72082625281785866-dummy.host.com:8984_solr-n_06)
> [n:dummy.host.com:8984_solr] o.a.s.c.a.OverseerTriggerThread A ZK
> error has occurred
>
>[junit4]   2> java.io.IOException:
> org.apache.zookeeper.KeeperException$SessionExpiredException:
> KeeperErrorCode = Session expired for /autoscaling.json
>
>[junit4]   2> at
> org.apache.solr.client.solrj.impl.ZkDistribStateManager.getAutoScalingConfig(ZkDistribStateManager.java:183)
>
>[junit4]   2> at
> org.apache.solr.client.solrj.cloud.autoscaling.DistribStateManager.getAutoScalingConfig(DistribStateManager.java:78)
>
>[junit4]   2> at
> org.apache.solr.cloud.autoscaling.OverseerTriggerThread.run(OverseerTriggerThread.java:126)
>
>[junit4]   2> at java.lang.Thread.run(Thread.java:745)
>
>[junit4]   2> Caused by:
> org.apache.zookeeper.KeeperException$SessionExpiredException:
> KeeperErrorCode = Session expired for /autoscaling.json
>
> On Tue, Apr 24, 2018 at 7:35 PM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
> wrote:
>
>> Hi Varun,
>>
>> Go ahead, I will start the build tomorrow.
>>
>> On Wed, Apr 25, 2018 at 1:21 AM Varun Thacker <va...@vthacker.in> wrote:
>>
>>> Hi Dat,
>>>
>>> What's the timeline in mind that you have for creating a Solr 7.3.1 RC?
>>>
>>> I want to backport SOLR-12065 / SOLR-11724 and I can wrap it up today
>>>
>>> On Mon, Apr 23, 2018 at 1:01 AM, Alan Woodward <romseyg...@gmail.com>
>>> wrote:
>>>
>>>> Done
>>>>
>>>> > On 23 Apr 2018, at 04:12, Đạt Cao Mạnh <caomanhdat...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi Alan,
>>>> >
>>>> > Can you backport LUCENE-8254 to branch_7_3?
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>>
>>>
>

Re: BugFix release 7.3.1

[Đạt Cao Mạnh]

Hi Varun,

Go ahead, I will start the build tomorrow.
On Wed, Apr 25, 2018 at 1:21 AM Varun Thacker <va...@vthacker.in> wrote:

> Hi Dat,
>
> What's the timeline in mind that you have for creating a Solr 7.3.1 RC?
>
> I want to backport SOLR-12065 / SOLR-11724 and I can wrap it up today
>
> On Mon, Apr 23, 2018 at 1:01 AM, Alan Woodward <romseyg...@gmail.com>
> wrote:
>
>> Done
>>
>> > On 23 Apr 2018, at 04:12, Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote:
>> >
>> > Hi Alan,
>> >
>> > Can you backport LUCENE-8254 to branch_7_3?
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: BugFix release 7.3.1

[Đạt Cao Mạnh]

Hi Alan,

Can you backport LUCENE-8254 to branch_7_3?

BugFix release 7.3.1

[Đạt Cao Mạnh]

Note: Resent another mail because the previous one missed 7.3.1 in the
title.
Hi,

There are some bugs get fixed in 7.4 are SOLR-12066, SOLR-12087, and
SOLR-12088 which can cause some annoying problems to users who are using
autoscaling framework (or frequently calling DeleteReplica API).
so I wanted to ask if anyone objects to a bugfix release for 7.3 (7.3.1). I
also volunteer to be the release manager for this one if it is accepted.

BugFix release

[Đạt Cao Mạnh]

Hi,

There are some bugs get fixed in 7.4 are SOLR-12066, SOLR-12087, and
SOLR-12088 which can cause some annoying problems to users who are using
autoscaling framework (or frequently calling DeleteReplica API).
so I wanted to ask if anyone objects to a bugfix release for 7.3 (7.3.1). I
also volunteer to be the release manager for this one if it is accepted.

Re: Welcome to the PMC

[Đạt Cao Mạnh]

Thanks, everyone!!


On Tue, Apr 3, 2018 at 10:17 AM David Smiley 
wrote:

> Welcome!
>
> On Mon, Apr 2, 2018 at 3:49 PM Adrien Grand  wrote:
>
>> I am pleased to announce that Cao Mạnh Đạt has accepted the PMC's
>> invitation to join.
>>
>> Welcome Đạt!
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Welcome Cao Mạnh Đạt to the PMC

[Đạt Cao Mạnh]

Thanks, everyone!!


On Tue, Apr 3, 2018 at 5:44 AM Joel Bernstein  wrote:

> Welcome Dat!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Mon, Apr 2, 2018 at 6:42 PM, Tomas Fernandez Lobbe 
> wrote:
>
>> Welcome Đạt!
>>
>>
>> On Apr 2, 2018, at 2:59 PM, Christian Moen  wrote:
>>
>> Congrats, Đạt!
>>
>> On Mon, Apr 2, 2018 at 11:48 PM Varun Thacker  wrote:
>>
>>> Congratulations and welcome Dat!
>>>
>>> On Mon, Apr 2, 2018 at 12:50 PM, Adrien Grand  wrote:
>>>
 Fixing the subject of the email.

 Le lun. 2 avr. 2018 à 21:48, Adrien Grand  a écrit :

> I am pleased to announce that Cao Mạnh Đạt has accepted the PMC's
> invitation to join.
>
> Welcome Đạt!
>

>>>
>>
>

Re: Lucene/Solr 7.3

[Đạt Cao Mạnh]

Hi Alan,

I committed the fix as well as resolve the issue.

Thanks!

On Tue, Mar 20, 2018 at 9:27 PM Alan Woodward <romseyg...@gmail.com> wrote:

> OK, thanks. Let me know when it’s in.
>
>
> On 20 Mar 2018, at 14:07, Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote:
>
> Hi  Alan, guys,
>
> I found a blocker issue SOLR-12129, I've already uploaded a patch and
> beasting the tests, if the result is good I will commit and notify your
> guys!
>
> Thanks!
>
> On Tue, Mar 20, 2018 at 2:37 AM Alan Woodward <romseyg...@gmail.com>
> wrote:
>
>> Go ahead!
>>
>>
>> On 19 Mar 2018, at 18:33, Andrzej Białecki <
>> andrzej.biale...@lucidworks.com> wrote:
>>
>> Alan,
>>
>> I would like to commit the change in SOLR-11407 (
>> 78d592d2fdfc64c227fc1bcb8fafa3d806fbb384) to branch_7_3. This fixes the
>> logic that waits for replica recovery and provides more details about any
>> failures.
>>
>> On 17 Mar 2018, at 13:01, Alan Woodward <romseyg...@gmail.com> wrote:
>>
>> I’d like to build the RC on Monday, but it depends on SOLR-12070.  I can
>> help debugging that if need be.
>>
>> +1 to backport your fixes
>>
>> On 17 Mar 2018, at 01:42, Varun Thacker <va...@vthacker.in> wrote:
>>
>> I was going through the blockers for 7.3 and only SOLR-12070 came up. Is
>> the fix complete for this Andrzej?
>>
>> @Alan : When do you plan on cutting an RC ? I committed SOLR-12083
>> yesterday and SOLR-12063 today to master/branch_7x. Both are important
>> fixes for CDCR so if you are okay I can backport it to the release branch
>>
>> On Fri, Mar 16, 2018 at 4:58 PM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
>> wrote:
>>
>>> Hi guys, Alan
>>>
>>> I committed the fix for SOLR-12110 to branch_7_3
>>>
>>> Thanks!
>>>
>>> On Fri, Mar 16, 2018 at 5:43 PM Đạt Cao Mạnh <caomanhdat...@gmail.com>
>>> wrote:
>>>
>>>> Hi Alan,
>>>>
>>>> Sure the issue is marked as Blocker for 7.3.
>>>>
>>>> On Fri, Mar 16, 2018 at 3:12 PM Alan Woodward <romseyg...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Đạt, could you mark the issue as a Blocker and let me know when
>>>>> it’s been resolved?
>>>>>
>>>>> On 16 Mar 2018, at 02:05, Đạt Cao Mạnh <caomanhdat...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi guys, Alan,
>>>>>
>>>>> I found a blocker issue SOLR-12110, when investigating test failure.
>>>>> I've already uploaded a patch and beasting the tests, if the result is 
>>>>> good
>>>>> I will commit soon.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward <romseyg...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Just realised that I don’t have an ASF Jenkins account - Uwe or
>>>>>> Steve, can you give me a hand setting up the 7.3 Jenkins jobs?
>>>>>>
>>>>>> Thanks, Alan
>>>>>>
>>>>>>
>>>>>> On 12 Mar 2018, at 09:32, Alan Woodward <romseyg...@gmail.com> wrote:
>>>>>>
>>>>>> I’ve created the 7.3 release branch.  I’ll leave 24 hours for
>>>>>> bug-fixes and doc patches and then create a release candidate.
>>>>>>
>>>>>> We’re now in feature-freeze for 7.3, so please bear in mind the
>>>>>> following:
>>>>>>
>>>>>>- No new features may be committed to the branch.
>>>>>>- Documentation patches, build patches and serious bug fixes may
>>>>>>be committed to the branch. However, you should submit *all* patches
>>>>>>you want to commit to Jira first to give others the chance to review 
>>>>>> and
>>>>>>possibly vote against the patch. Keep in mind that it is our main 
>>>>>> intention
>>>>>>to keep the branch as stable as possible.
>>>>>>- All patches that are intended for the branch should first be
>>>>>>committed to the unstable branch, merged into the stable branch, and 
>>>>>> then
>>>>>>into the current release branch.
>>>>>>- Normal unstable and stable branch development may continue as
>>>>>> 

Re: Lucene/Solr 7.3

[Đạt Cao Mạnh]

Hi  Alan, guys,

I found a blocker issue SOLR-12129, I've already uploaded a patch and
beasting the tests, if the result is good I will commit and notify your
guys!

Thanks!

On Tue, Mar 20, 2018 at 2:37 AM Alan Woodward <romseyg...@gmail.com> wrote:

> Go ahead!
>
>
> On 19 Mar 2018, at 18:33, Andrzej Białecki <
> andrzej.biale...@lucidworks.com> wrote:
>
> Alan,
>
> I would like to commit the change in SOLR-11407 (
> 78d592d2fdfc64c227fc1bcb8fafa3d806fbb384) to branch_7_3. This fixes the
> logic that waits for replica recovery and provides more details about any
> failures.
>
> On 17 Mar 2018, at 13:01, Alan Woodward <romseyg...@gmail.com> wrote:
>
> I’d like to build the RC on Monday, but it depends on SOLR-12070.  I can
> help debugging that if need be.
>
> +1 to backport your fixes
>
> On 17 Mar 2018, at 01:42, Varun Thacker <va...@vthacker.in> wrote:
>
> I was going through the blockers for 7.3 and only SOLR-12070 came up. Is
> the fix complete for this Andrzej?
>
> @Alan : When do you plan on cutting an RC ? I committed SOLR-12083
> yesterday and SOLR-12063 today to master/branch_7x. Both are important
> fixes for CDCR so if you are okay I can backport it to the release branch
>
> On Fri, Mar 16, 2018 at 4:58 PM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
> wrote:
>
>> Hi guys, Alan
>>
>> I committed the fix for SOLR-12110 to branch_7_3
>>
>> Thanks!
>>
>> On Fri, Mar 16, 2018 at 5:43 PM Đạt Cao Mạnh <caomanhdat...@gmail.com>
>> wrote:
>>
>>> Hi Alan,
>>>
>>> Sure the issue is marked as Blocker for 7.3.
>>>
>>> On Fri, Mar 16, 2018 at 3:12 PM Alan Woodward <romseyg...@gmail.com>
>>> wrote:
>>>
>>>> Thanks Đạt, could you mark the issue as a Blocker and let me know when
>>>> it’s been resolved?
>>>>
>>>> On 16 Mar 2018, at 02:05, Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote:
>>>>
>>>> Hi guys, Alan,
>>>>
>>>> I found a blocker issue SOLR-12110, when investigating test failure.
>>>> I've already uploaded a patch and beasting the tests, if the result is good
>>>> I will commit soon.
>>>>
>>>> Thanks!
>>>>
>>>> On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward <romseyg...@gmail.com>
>>>> wrote:
>>>>
>>>>> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve,
>>>>> can you give me a hand setting up the 7.3 Jenkins jobs?
>>>>>
>>>>> Thanks, Alan
>>>>>
>>>>>
>>>>> On 12 Mar 2018, at 09:32, Alan Woodward <romseyg...@gmail.com> wrote:
>>>>>
>>>>> I’ve created the 7.3 release branch.  I’ll leave 24 hours for
>>>>> bug-fixes and doc patches and then create a release candidate.
>>>>>
>>>>> We’re now in feature-freeze for 7.3, so please bear in mind the
>>>>> following:
>>>>>
>>>>>- No new features may be committed to the branch.
>>>>>- Documentation patches, build patches and serious bug fixes may
>>>>>be committed to the branch. However, you should submit *all* patches
>>>>>you want to commit to Jira first to give others the chance to review 
>>>>> and
>>>>>possibly vote against the patch. Keep in mind that it is our main 
>>>>> intention
>>>>>to keep the branch as stable as possible.
>>>>>- All patches that are intended for the branch should first be
>>>>>committed to the unstable branch, merged into the stable branch, and 
>>>>> then
>>>>>into the current release branch.
>>>>>- Normal unstable and stable branch development may continue as
>>>>>usual. However, if you plan to commit a big change to the unstable 
>>>>> branch
>>>>>while the branch feature freeze is in effect, think twice: can't the
>>>>>addition wait a couple more days? Merges of bug fixes into the branch 
>>>>> may
>>>>>become more difficult.
>>>>>- *Only* Jira issues with Fix version “7.3" and priority "Blocker"
>>>>>will delay a release candidate build.
>>>>>
>>>>>
>>>>>
>>>>> On 9 Mar 2018, at 16:43, Alan Woodward <romseyg...@gmail.com> wrote:
>>>>>
>>>>> FYI I’m still recove

Re: Lucene/Solr 7.3

[Đạt Cao Mạnh]

Hi guys, Alan

I committed the fix for SOLR-12110 to branch_7_3

Thanks!

On Fri, Mar 16, 2018 at 5:43 PM Đạt Cao Mạnh <caomanhdat...@gmail.com>
wrote:

> Hi Alan,
>
> Sure the issue is marked as Blocker for 7.3.
>
> On Fri, Mar 16, 2018 at 3:12 PM Alan Woodward <romseyg...@gmail.com>
> wrote:
>
>> Thanks Đạt, could you mark the issue as a Blocker and let me know when
>> it’s been resolved?
>>
>> On 16 Mar 2018, at 02:05, Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote:
>>
>> Hi guys, Alan,
>>
>> I found a blocker issue SOLR-12110, when investigating test failure. I've
>> already uploaded a patch and beasting the tests, if the result is good I
>> will commit soon.
>>
>> Thanks!
>>
>> On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward <romseyg...@gmail.com>
>> wrote:
>>
>>> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve,
>>> can you give me a hand setting up the 7.3 Jenkins jobs?
>>>
>>> Thanks, Alan
>>>
>>>
>>> On 12 Mar 2018, at 09:32, Alan Woodward <romseyg...@gmail.com> wrote:
>>>
>>> I’ve created the 7.3 release branch.  I’ll leave 24 hours for bug-fixes
>>> and doc patches and then create a release candidate.
>>>
>>> We’re now in feature-freeze for 7.3, so please bear in mind the
>>> following:
>>>
>>>- No new features may be committed to the branch.
>>>- Documentation patches, build patches and serious bug fixes may be
>>>committed to the branch. However, you should submit *all* patches
>>>you want to commit to Jira first to give others the chance to review and
>>>possibly vote against the patch. Keep in mind that it is our main 
>>> intention
>>>to keep the branch as stable as possible.
>>>- All patches that are intended for the branch should first be
>>>committed to the unstable branch, merged into the stable branch, and then
>>>into the current release branch.
>>>- Normal unstable and stable branch development may continue as
>>>usual. However, if you plan to commit a big change to the unstable branch
>>>while the branch feature freeze is in effect, think twice: can't the
>>>addition wait a couple more days? Merges of bug fixes into the branch may
>>>become more difficult.
>>>- *Only* Jira issues with Fix version “7.3" and priority "Blocker"
>>>will delay a release candidate build.
>>>
>>>
>>>
>>> On 9 Mar 2018, at 16:43, Alan Woodward <romseyg...@gmail.com> wrote:
>>>
>>> FYI I’m still recovering from my travels, so I’m going to create the
>>> release branch on Monday instead.
>>>
>>> On 27 Feb 2018, at 18:51, Cassandra Targett <casstarg...@gmail.com>
>>> wrote:
>>>
>>> I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts
>>> RC is ready, so this is a great time to remind folks that if you've got
>>> Ref Guide changes to be done, you've got a couple weeks. If you're stuck or
>>> not sure what to do, let me know & I'm happy to help you out.
>>>
>>> Eventually we'd like to release both the Ref Guide and Lucene/Solr with
>>> the same release process, so this will be a big first test to see how ready
>>> for that we are.
>>>
>>> On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless <
>>> luc...@mikemccandless.com> wrote:
>>>
>>>> +1
>>>>
>>>> Mike McCandless
>>>>
>>>> http://blog.mikemccandless.com
>>>>
>>>> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
>>>> alan.woodw...@romseysoftware.co.uk> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> It’s been a couple of months since the 7.2 release, and we’ve
>>>>> accumulated some nice new features since then.  I’d like to volunteer to 
>>>>> be
>>>>> RM for a 7.3 release.
>>>>>
>>>>> I’m travelling for the next couple of weeks, so I would plan to create
>>>>> the release branch two weeks today, on the 9th March (unless anybody else
>>>>> wants to do it sooner, of course :)
>>>>>
>>>>> - Alan
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>

Re: Lucene/Solr 7.3

[Đạt Cao Mạnh]

Hi Alan,

Sure the issue is marked as Blocker for 7.3.

On Fri, Mar 16, 2018 at 3:12 PM Alan Woodward <romseyg...@gmail.com> wrote:

> Thanks Đạt, could you mark the issue as a Blocker and let me know when
> it’s been resolved?
>
> On 16 Mar 2018, at 02:05, Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote:
>
> Hi guys, Alan,
>
> I found a blocker issue SOLR-12110, when investigating test failure. I've
> already uploaded a patch and beasting the tests, if the result is good I
> will commit soon.
>
> Thanks!
>
> On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward <romseyg...@gmail.com>
> wrote:
>
>> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve,
>> can you give me a hand setting up the 7.3 Jenkins jobs?
>>
>> Thanks, Alan
>>
>>
>> On 12 Mar 2018, at 09:32, Alan Woodward <romseyg...@gmail.com> wrote:
>>
>> I’ve created the 7.3 release branch.  I’ll leave 24 hours for bug-fixes
>> and doc patches and then create a release candidate.
>>
>> We’re now in feature-freeze for 7.3, so please bear in mind the following:
>>
>>- No new features may be committed to the branch.
>>- Documentation patches, build patches and serious bug fixes may be
>>committed to the branch. However, you should submit *all* patches you
>>want to commit to Jira first to give others the chance to review and
>>possibly vote against the patch. Keep in mind that it is our main 
>> intention
>>to keep the branch as stable as possible.
>>- All patches that are intended for the branch should first be
>>committed to the unstable branch, merged into the stable branch, and then
>>into the current release branch.
>>- Normal unstable and stable branch development may continue as
>>usual. However, if you plan to commit a big change to the unstable branch
>>while the branch feature freeze is in effect, think twice: can't the
>>addition wait a couple more days? Merges of bug fixes into the branch may
>>become more difficult.
>>- *Only* Jira issues with Fix version “7.3" and priority "Blocker"
>>will delay a release candidate build.
>>
>>
>>
>> On 9 Mar 2018, at 16:43, Alan Woodward <romseyg...@gmail.com> wrote:
>>
>> FYI I’m still recovering from my travels, so I’m going to create the
>> release branch on Monday instead.
>>
>> On 27 Feb 2018, at 18:51, Cassandra Targett <casstarg...@gmail.com>
>> wrote:
>>
>> I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts
>> RC is ready, so this is a great time to remind folks that if you've got
>> Ref Guide changes to be done, you've got a couple weeks. If you're stuck or
>> not sure what to do, let me know & I'm happy to help you out.
>>
>> Eventually we'd like to release both the Ref Guide and Lucene/Solr with
>> the same release process, so this will be a big first test to see how ready
>> for that we are.
>>
>> On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> +1
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
>>> alan.woodw...@romseysoftware.co.uk> wrote:
>>>
>>>> Hi all,
>>>>
>>>> It’s been a couple of months since the 7.2 release, and we’ve
>>>> accumulated some nice new features since then.  I’d like to volunteer to be
>>>> RM for a 7.3 release.
>>>>
>>>> I’m travelling for the next couple of weeks, so I would plan to create
>>>> the release branch two weeks today, on the 9th March (unless anybody else
>>>> wants to do it sooner, of course :)
>>>>
>>>> - Alan
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>>
>>>
>>
>>
>>
>>
>

Re: Lucene/Solr 7.3

[Đạt Cao Mạnh]

Hi guys, Alan,

I found a blocker issue SOLR-12110, when investigating test failure. I've
already uploaded a patch and beasting the tests, if the result is good I
will commit soon.

Thanks!

On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward  wrote:

> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve, can
> you give me a hand setting up the 7.3 Jenkins jobs?
>
> Thanks, Alan
>
>
> On 12 Mar 2018, at 09:32, Alan Woodward  wrote:
>
> I’ve created the 7.3 release branch.  I’ll leave 24 hours for bug-fixes
> and doc patches and then create a release candidate.
>
> We’re now in feature-freeze for 7.3, so please bear in mind the following:
>
>- No new features may be committed to the branch.
>- Documentation patches, build patches and serious bug fixes may be
>committed to the branch. However, you should submit *all* patches you
>want to commit to Jira first to give others the chance to review and
>possibly vote against the patch. Keep in mind that it is our main intention
>to keep the branch as stable as possible.
>- All patches that are intended for the branch should first be
>committed to the unstable branch, merged into the stable branch, and then
>into the current release branch.
>- Normal unstable and stable branch development may continue as usual.
>However, if you plan to commit a big change to the unstable branch while
>the branch feature freeze is in effect, think twice: can't the addition
>wait a couple more days? Merges of bug fixes into the branch may become
>more difficult.
>- *Only* Jira issues with Fix version “7.3" and priority "Blocker"
>will delay a release candidate build.
>
>
>
> On 9 Mar 2018, at 16:43, Alan Woodward  wrote:
>
> FYI I’m still recovering from my travels, so I’m going to create the
> release branch on Monday instead.
>
> On 27 Feb 2018, at 18:51, Cassandra Targett  wrote:
>
> I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts
> RC is ready, so this is a great time to remind folks that if you've got
> Ref Guide changes to be done, you've got a couple weeks. If you're stuck or
> not sure what to do, let me know & I'm happy to help you out.
>
> Eventually we'd like to release both the Ref Guide and Lucene/Solr with
> the same release process, so this will be a big first test to see how ready
> for that we are.
>
> On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> +1
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
>> alan.woodw...@romseysoftware.co.uk> wrote:
>>
>>> Hi all,
>>>
>>> It’s been a couple of months since the 7.2 release, and we’ve
>>> accumulated some nice new features since then.  I’d like to volunteer to be
>>> RM for a 7.3 release.
>>>
>>> I’m travelling for the next couple of weeks, so I would plan to create
>>> the release branch two weeks today, on the 9th March (unless anybody else
>>> wants to do it sooner, of course :)
>>>
>>> - Alan
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>
>
>
>

Re: Welcome Jason Gerlowski as committer

[Đạt Cao Mạnh]

Welcome Jason!
On Thu, Feb 8, 2018 at 5:33 PM Anshum Gupta  wrote:

> Welcome and congratulations Jason! Looking forward to working with you
> (again) :)
>
>
> On Fri, Feb 9, 2018 at 6:48 AM Varun Thacker  wrote:
>
>> Welcome and congrats Jason!
>>
>> On Thu, Feb 8, 2018 at 9:02 AM, David Smiley 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> It's my pleasure to announce that Jason Gerlowski is our latest
>>> committer for Lucene/Solr in recognition for his contributions to the
>>> project!  Please join me in welcoming him.  Jason, it's tradition for
>>> you to introduce yourself with a brief bio.
>>>
>>> Congratulations and Welcome!
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>>
>>

Re: Welcome Ignacio Vera as Lucene/Solr committer

[Đạt Cao Mạnh]

Welcome Ignacio!

On Fri, Jan 12, 2018 at 1:53 PM Christian Moen  wrote:

> Congrats!
>
> Best,
> Christian
>
> On Fri, Jan 12, 2018 at 1:35 AM Adrien Grand  wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Ignacio Vera as the latest Lucene/Solr
>> committer.
>> Ignacio, it's tradition for you to introduce yourself with a brief bio.
>>
>> Congratulations and Welcome!
>>
>

Re: BugFix release 7.2.1

[Đạt Cao Mạnh]

Hi all,

I will work on SOLR-11771
 today,
It is a simple fix and will be great if it get fixed in 7.2.1

On Fri, Jan 5, 2018 at 11:23 PM Erick Erickson 
wrote:

> Neither of those Solr fixes are earth shatteringly important, they've both
> been around for quite a while. I don't think it's urgent to include them.
>
> That said, they're pretty simple and isolated so worth doing if Jim is
> willing. But not worth straining much. I was just clearing out some backlog
> over vacation.
>
> Strictly up to you Jim.
>
> Erick
>
> On Fri, Jan 5, 2018 at 6:54 AM, David Smiley 
> wrote:
>
>> https://issues.apache.org/jira/browse/SOLR-11809 is in progress, should
>> be easy and I think definitely worth backporting
>>
>> On Fri, Jan 5, 2018 at 8:52 AM Adrien Grand  wrote:
>>
>>> +1
>>>
>>> Looking at the changelog, 7.3 has 3 bug fixes for now: LUCENE-8077,
>>> SOLR-11783 and SOLR-11555. The Lucene change doesn't seem worth
>>> backporting, but maybe the Solr changes should?
>>>
>>> Le ven. 5 janv. 2018 à 12:40, jim ferenczi  a
>>> écrit :
>>>
 Hi,
 We discovered a bad bug in 7x that affects indices created in 6x with
 Lucene54DocValues format. The SortedNumericDocValues created with this
 format have a bug when advanceExact is used, the values retrieved for the
 docs when advanceExact returns true are invalid (the pointer to the values
 is not updated):
 https://issues.apache.org/jira/browse/LUCENE-8117
 This affects all indices created in 6x with sorted numeric doc values
 so I wanted to ask if anyone objects to a bugfix release for 7.2 (7.2.1). I
 also volunteer to be the release manager for this one if it is accepted.

 Jim

>>>
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
>

Re: Welcome Hrishikesh Gadre as Lucene/Solr committer

[Đạt Cao Mạnh]

Welcome!
On Sat, Sep 30, 2017 at 10:14 AM David Smiley 
wrote:

> Welcome Hrishikesh!  Well deserved.
> ~ David
>
>
> On Fri, Sep 29, 2017 at 1:23 PM Yonik Seeley  wrote:
>
>> Hi All,
>>
>> Please join me in welcoming Hrishikesh Gadre as the latest Lucene/Solr
>> committer.
>> Hrishikesh, it's tradition for you to introduce yourself with a brief bio.
>>
>> Congrats and Welcome!
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Welcome Mike Drob as Lucene/Solr committer

[Đạt Cao Mạnh]

Congrats Mike!
On Tue, May 9, 2017 at 7:35 AM Dennis Gove  wrote:

> Welcome Mike!
>
> On Mon, May 8, 2017 at 11:42 AM, Mark Miller 
> wrote:
>
>> I'm pleased to announce that Mike Drob has accepted the PMC's
>> invitation to become a committer.
>>
>> Mike, it's tradition that you introduce yourself with a brief bio /
>> origin story, explaining how you arrived here.
>>
>> Your existing Apache handle has already added to the “lucene" LDAP
>> group, so you now have commit privileges.
>>
>> Please celebrate this rite of passage, and confirm that the right
>> karma has in fact enabled, by embarking on the challenge of adding
>> yourself to the committers section of the Who We Are page on the
>> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>> bookmarklet
>> at the bottom of the page here: https://cms.apache.org/#bookmark -
>> more info here http://www.apache.org/dev/cms.html).
>>
>> Congratulations and welcome!
>> --
>> - Mark
>> about.me/markrmiller
>>
>

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Đạt Cao Mạnh]

Hi Joel, It's totally up to you to release this version or waiting for the
fix.
On Thu, Apr 13, 2017 at 8:46 PM Đạt Cao Mạnh <caomanhdat...@gmail.com>
wrote:

> I spent today to fix Steve test failure for SOLR-10420. Can not reproduce
> the failure with my machine, so I came up with 2 patches that I think can
> solve the problem. But they couldn't.
>
> Steve just has posted DEBUG log for the failure. So I will have more
> information to work on tomorrow.
> On Thu, Apr 13, 2017 at 8:29 PM Mark Miller <markrmil...@gmail.com> wrote:
>
>> Releases don't come for free. That is a nasty bug. My 2 cents would be to
>> relax for a day or two and see what comes of a fix for that issue. It
>> shouldn't hold things up a long time, but not holding things up for a short
>> bit seems counter productive to me. The idea that anyone legitimate is
>> slapping in releases as fast as they come out in a production env is hard
>> for me to buy. Apache really should move on the fastest unit of time of a
>> couple days in most cases.
>>
>> I like that over the years we have become a lot more pro, you can't stop
>> the release train baby, at best you can pause it 5 seconds. But now that we
>> have enabled the train to run everyone over, might be worth stepping it
>> back just half a step.
>>
>> - Mark
>>
>> On Wed, Apr 12, 2017 at 11:15 AM Joel Bernstein <joels...@gmail.com>
>> wrote:
>>
>>> Here are the release notes for bug fixes that are ready to ship:
>>>
>>> https://wiki.apache.org/lucene-java/ReleaseNote651
>>> https://wiki.apache.org/solr/ReleaseNote651
>>>
>>> There are Solr bug fixes that affect non-Solr Cloud systems, and Lucene
>>> bugs. So there will be plenty of users who can benefit from a 6.5.1
>>> release.
>>>
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Wed, Apr 12, 2017 at 10:58 AM, Cassandra Targett <
>>> casstarg...@gmail.com> wrote:
>>>
>>> No, Joel initially proposed 6.5.1 to fix SOLR-10341 (back on 30 Mar).
>>> SOLR-10420 was reported after he'd already announced his intention to
>>> RM a 6.5.1.
>>>
>>> On Wed, Apr 12, 2017 at 9:54 AM, Walter Underwood <wun...@wunderwood.org>
>>> wrote:
>>> > SOLR-10420 is the only reason I would install a 6.5.1. That is a
>>> serious bug
>>> > that affects every user of Solr Cloud.
>>> >
>>> > That bug was the reason why the 6.5.1 process was started, right?
>>> >
>>> > wunder
>>> > Walter Underwood
>>> > wun...@wunderwood.org
>>> > http://observer.wunderwood.org/  (my blog)
>>> >
>>> >
>>> > On Apr 12, 2017, at 7:14 AM, Joel Bernstein <joels...@gmail.com>
>>> wrote:
>>> >
>>> > We have a couple options here:
>>> >
>>> > 1) The vote ends for this release tomorrow. We can continue with this
>>> > release and ship 6.5.1. In the background start working on 6.5.2.
>>> >
>>> > 2) Or we could respin 6.5.1 to include SOLR-10420. The problem with
>>> this is
>>> > it restarts the clock on the 6.5.1 and delays other bug fixes.
>>> >
>>> > Joel Bernstein
>>> > http://joelsolr.blogspot.com/
>>> >
>>> > On Wed, Apr 12, 2017 at 9:48 AM, Đạt Cao Mạnh <caomanhdat...@gmail.com
>>> >
>>> > wrote:
>>> >>
>>> >> Sorry Joel, but can we wait for SOLR-10420, this is a serious bug that
>>> >> leaking one SolrZkClient per second on the Overseer node.
>>> >>
>>> >> On Tue, Apr 11, 2017 at 6:34 PM Tommaso Teofili
>>> >> <tommaso.teof...@gmail.com> wrote:
>>> >>>
>>> >>> +1
>>> >>>
>>> >>> SUCCESS! [2:25:09.313218]
>>> >>>
>>> >>> Tommaso
>>> >>>
>>> >>> Il giorno mar 11 apr 2017 alle ore 06:47 Shalin Shekhar Mangar
>>> >>> <shalinman...@gmail.com> ha scritto:
>>> >>>>
>>> >>>> +1
>>> >>>>
>>> >>>> SUCCESS! [2:03:24.673867]
>>> >>>>
>>> >>>> On Mon, Apr 10, 2017 at 8:31 AM, Joel Bernstein <joels...@gmail.com
>>> >
>>> >>>> wrote:
>>> >>>> > Please vote for release candidate 1 for Lucene/Solr 6.5.1
&

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Đạt Cao Mạnh]

I spent today to fix Steve test failure for SOLR-10420. Can not reproduce
the failure with my machine, so I came up with 2 patches that I think can
solve the problem. But they couldn't.

Steve just has posted DEBUG log for the failure. So I will have more
information to work on tomorrow.
On Thu, Apr 13, 2017 at 8:29 PM Mark Miller <markrmil...@gmail.com> wrote:

> Releases don't come for free. That is a nasty bug. My 2 cents would be to
> relax for a day or two and see what comes of a fix for that issue. It
> shouldn't hold things up a long time, but not holding things up for a short
> bit seems counter productive to me. The idea that anyone legitimate is
> slapping in releases as fast as they come out in a production env is hard
> for me to buy. Apache really should move on the fastest unit of time of a
> couple days in most cases.
>
> I like that over the years we have become a lot more pro, you can't stop
> the release train baby, at best you can pause it 5 seconds. But now that we
> have enabled the train to run everyone over, might be worth stepping it
> back just half a step.
>
> - Mark
>
> On Wed, Apr 12, 2017 at 11:15 AM Joel Bernstein <joels...@gmail.com>
> wrote:
>
>> Here are the release notes for bug fixes that are ready to ship:
>>
>> https://wiki.apache.org/lucene-java/ReleaseNote651
>> https://wiki.apache.org/solr/ReleaseNote651
>>
>> There are Solr bug fixes that affect non-Solr Cloud systems, and Lucene
>> bugs. So there will be plenty of users who can benefit from a 6.5.1
>> release.
>>
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Apr 12, 2017 at 10:58 AM, Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>>
>> No, Joel initially proposed 6.5.1 to fix SOLR-10341 (back on 30 Mar).
>> SOLR-10420 was reported after he'd already announced his intention to
>> RM a 6.5.1.
>>
>> On Wed, Apr 12, 2017 at 9:54 AM, Walter Underwood <wun...@wunderwood.org>
>> wrote:
>> > SOLR-10420 is the only reason I would install a 6.5.1. That is a
>> serious bug
>> > that affects every user of Solr Cloud.
>> >
>> > That bug was the reason why the 6.5.1 process was started, right?
>> >
>> > wunder
>> > Walter Underwood
>> > wun...@wunderwood.org
>> > http://observer.wunderwood.org/  (my blog)
>> >
>> >
>> > On Apr 12, 2017, at 7:14 AM, Joel Bernstein <joels...@gmail.com> wrote:
>> >
>> > We have a couple options here:
>> >
>> > 1) The vote ends for this release tomorrow. We can continue with this
>> > release and ship 6.5.1. In the background start working on 6.5.2.
>> >
>> > 2) Or we could respin 6.5.1 to include SOLR-10420. The problem with
>> this is
>> > it restarts the clock on the 6.5.1 and delays other bug fixes.
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> > On Wed, Apr 12, 2017 at 9:48 AM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
>> > wrote:
>> >>
>> >> Sorry Joel, but can we wait for SOLR-10420, this is a serious bug that
>> >> leaking one SolrZkClient per second on the Overseer node.
>> >>
>> >> On Tue, Apr 11, 2017 at 6:34 PM Tommaso Teofili
>> >> <tommaso.teof...@gmail.com> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> SUCCESS! [2:25:09.313218]
>> >>>
>> >>> Tommaso
>> >>>
>> >>> Il giorno mar 11 apr 2017 alle ore 06:47 Shalin Shekhar Mangar
>> >>> <shalinman...@gmail.com> ha scritto:
>> >>>>
>> >>>> +1
>> >>>>
>> >>>> SUCCESS! [2:03:24.673867]
>> >>>>
>> >>>> On Mon, Apr 10, 2017 at 8:31 AM, Joel Bernstein <joels...@gmail.com>
>> >>>> wrote:
>> >>>> > Please vote for release candidate 1 for Lucene/Solr 6.5.1
>> >>>> >
>> >>>> > The artifacts can be downloaded from:
>> >>>> >
>> >>>> >
>> >>>> >
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>> >>>> >
>> >>>> > You can run the smoke tester directly with this command:
>> >>>> >
>> >>>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >>>> >
>> >>>> >
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>> >>>> >
>> >>>> > Here's my +1
>> >>>> >
>> >>>> > SUCCESS! [0:40:54.049621]
>> >>>> >
>> >>>> > Joel Bernstein
>> >>>> > http://joelsolr.blogspot.com/
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Regards,
>> >>>> Shalin Shekhar Mangar.
>> >>>>
>> >>>> -
>> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>>
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> --
> - Mark
> about.me/markrmiller
>

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Đạt Cao Mạnh]

Hi Andrien, the patch seems close to be committed.
I will work on one test failure and commit the patch tomorrow. If it takes
longer than that. I think we have to wait for 6.5.2
On Wed, Apr 12, 2017 at 9:33 PM Adrien Grand <jpou...@gmail.com> wrote:

> Agreed with David. I might reconsider if other bugs block the next RC, but
> I think the best path forward is to fix that bad memory leak and rebuild a
> RC. How much work is it to get a fix for that bug committed?
>
> Le mer. 12 avr. 2017 à 16:27, David Smiley <david.w.smi...@gmail.com> a
> écrit :
>
> I'd prefer adding bug fixes to 6.5.1 rather than have an inevitable 6.5.2
> when we know 6.5.1 contains known serious bugs.  No big deal to me though.
>
> On Wed, Apr 12, 2017 at 10:14 AM Joel Bernstein <joels...@gmail.com>
> wrote:
>
> We have a couple options here:
>
> 1) The vote ends for this release tomorrow. We can continue with this
> release and ship 6.5.1. In the background start working on 6.5.2.
>
> 2) Or we could respin 6.5.1 to include SOLR-10420. The problem with this
> is it restarts the clock on the 6.5.1 and delays other bug fixes.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Apr 12, 2017 at 9:48 AM, Đạt Cao Mạnh <caomanhdat...@gmail.com>
> wrote:
>
> Sorry Joel, but can we wait for SOLR-10420, this is a serious bug that
> leaking one SolrZkClient per second on the Overseer node.
>
> On Tue, Apr 11, 2017 at 6:34 PM Tommaso Teofili <tommaso.teof...@gmail.com>
> wrote:
>
> +1
>
> SUCCESS! [2:25:09.313218]
>
> Tommaso
>
> Il giorno mar 11 apr 2017 alle ore 06:47 Shalin Shekhar Mangar <
> shalinman...@gmail.com> ha scritto:
>
> +1
>
> SUCCESS! [2:03:24.673867]
>
> On Mon, Apr 10, 2017 at 8:31 AM, Joel Bernstein <joels...@gmail.com>
> wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.5.1
> >
> > The artifacts can be downloaded from:
> >
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
> >
> > Here's my +1
> >
> > SUCCESS! [0:40:54.049621 <049%20621>]
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Đạt Cao Mạnh]

Sorry Joel, but can we wait for SOLR-10420, this is a serious bug that
leaking one SolrZkClient per second on the Overseer node.

On Tue, Apr 11, 2017 at 6:34 PM Tommaso Teofili 
wrote:

> +1
>
> SUCCESS! [2:25:09.313218]
>
> Tommaso
>
> Il giorno mar 11 apr 2017 alle ore 06:47 Shalin Shekhar Mangar <
> shalinman...@gmail.com> ha scritto:
>
> +1
>
> SUCCESS! [2:03:24.673867]
>
> On Mon, Apr 10, 2017 at 8:31 AM, Joel Bernstein 
> wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.5.1
> >
> > The artifacts can be downloaded from:
> >
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
> >
> > Here's my +1
> >
> > SUCCESS! [0:40:54.049621 <049%20621>]
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Đạt Cao Mạnh]

Hi Alexandre,
I think SOLR-8045 can be closed.

On Wed, Mar 22, 2017 at 7:33 AM Alexandre Rafalovitch 
wrote:

> Is SOLR-8045 (v2 API URLs) resolved in 6.5? Because it is listed as
> reopened but also in the release notes as shipped.
>
> Regards,
>Alex.
>
>
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 21 March 2017 at 17:55, jim ferenczi  wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.5.0
> >
> > The artifacts can be downloaded from:
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >
> > Here's my +1
> > SUCCESS! [0:49:02.989006]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[Đạt Cao Mạnh]

Congratulations and welcome Toke!


On Thu, Feb 16, 2017 at 5:17 PM Tommaso Teofili 
wrote:

> Congrats and welcome Toke!
>
> Regards,
> Tommaso
>
> Il giorno gio 16 feb 2017 alle ore 10:00 Shalin Shekhar Mangar <
> shalinman...@gmail.com> ha scritto:
>
> Congratulations and welcome Toke!
>
> On Tue, Feb 14, 2017 at 4:09 AM, Jan Høydahl 
> wrote:
> > I'm pleased to announce that Toke Eskildsen has accepted the Lucene
> > PMC's invitation to become a committer.
> >
> > Toke, it's tradition that you introduce yourself with a brief bio.
> >
> > Your account "toke" has been added to the “lucene" LDAP group, so you
> > now have commit privileges. Please test this by adding yourself to the
> > committers section of the Who We Are page on the website:
> >  (instructions here
> > ).
> >
> > The ASF dev page also has lots of useful links: <
> http://www.apache.org/dev/>.
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Cao Manh Dat as a Lucene/Solr committer

[Đạt Cao Mạnh]

Thanks to everyone! I still can not believe this is true.

Brief intro:
I started out with Lucene since I was a student at university, by writing a
Vietnamese Analyzer for Lucene. But I didn't realize how great is open
source/ apache projects.

After college, I joined Viettel and worked on building a search engine for
Vietnamese. Then I found a bug on Lucene (LUCENE-6558) and decided to
contribute back to the community. By contributing the first patch to Lucene
(LUCENE-6558). I realized that, how wonderful to work with open source and
how nicely people at Lucene/Solr are. Especially Joel who help me a lot at
complete SOLR-9252.

After that experience I joined Lucidworks, everything is great here. Since
then I've worked on SolrCloud issues and helped a lot by Shalin.

P/S : I still can not believe this is true.

On Tue, Jan 10, 2017 at 7:30 AM Yonik Seeley  wrote:

> Congrats Dat!
>
> -Yonik
>
>
> On Mon, Jan 9, 2017 at 10:57 AM, Joel Bernstein 
> wrote:
> > I'm pleased to announce that Cao Manh Dat has accepted the Lucene
> > PMC's invitation to become a committer.
> >
> > Dat, it's tradition that you introduce yourself with a brief bio.
> >
> > Your account has been added to the “lucene" LDAP group, so you
> > now have commit privileges. Please test this by adding yourself to the
> > committers section of the Who We Are page on the website:
> >  (instructions here
> > ).
> >
> > The ASF dev page also has lots of useful links:
> > .
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Write buffering updates to temporary files?

[Đạt Cao Mạnh]

Do you think we should raise an issue for this problem?

On Wed, Dec 28, 2016 at 12:58 PM David Smiley <david.w.smi...@gmail.com>
wrote:

> I agree that using a single tlog for 2 purposes is confusing.  Perhaps a
> separate tlog purely for buffering purposes during recovery/peer-sync etc.
> be clearer?  You said "another separate file" but I imagine we can use our
> tlog code but another instance pointed to another directory.
>
> FWIW I actually question if buffering should happen at all due to the
> complexity it brings (e.g. SOLR-8030) vs blocking then failing if blocked
> for too long... but I guess that ship has sailed.
>
> On Tue, Dec 27, 2016 at 5:52 PM Đạt Cao Mạnh <caomanhdat...@gmail.com>
> wrote:
>
> Currently, we write buffering logs to current tlog and not apply that
> updates to index. Then we rely on replay log to apply that updates to
> index. But at the same time there are some updates also write to current
> tlog and applied to the index.
>
> For example, during peersync, if new updates come to replica we will end
> up with this tlog
> tlog : old1, new1, new2, old2, new3, old3
> old updates belong to peersync, and these updates are applied to the index.
> new updates belong to buffering updates, and these updates are not applied
> to the index.
>
> But writing all the updates to same current tlog make code base very
> complex. Should we write buffering updates to another temporary file?
>
> By doing this, it will help our code base simpler. It also makes replica
> recovery for SOLR-9835 more easier. Because after peersync success we can
> copy new updates from temporary file to current tlog, for example
> tlog : old1, old2, old3
> temporary tlog : new1, new2, new3
> -->
> tlog : old1, old2, old3, new1, new2, new3
>
> Note that in  SOLR-9835 we can not rely on fingerprint for peersync
> because updates are not applied to replicas.
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Write buffering updates to temporary files?

[Đạt Cao Mạnh]

Currently, we write buffering logs to current tlog and not apply that
updates to index. Then we rely on replay log to apply that updates to
index. But at the same time there are some updates also write to current
tlog and applied to the index.

For example, during peersync, if new updates come to replica we will end up
with this tlog
tlog : old1, new1, new2, old2, new3, old3
old updates belong to peersync, and these updates are applied to the index.
new updates belong to buffering updates, and these updates are not applied
to the index.

But writing all the updates to same current tlog make code base very
complex. Should we write buffering updates to another temporary file?

By doing this, it will help our code base simpler. It also makes replica
recovery for SOLR-9835 more easier. Because after peersync success we can
copy new updates from temporary file to current tlog, for example
tlog : old1, old2, old3
temporary tlog : new1, new2, new3
-->
tlog : old1, old2, old3, new1, new2, new3

Note that in  SOLR-9835 we can not rely on fingerprint for peersync because
updates are not applied to replicas.

Re: 5.4.1 release

[Đạt Cao Mạnh]

If we intend to release 5.4.1. Please look at this issue (submited a patch
several weeks ago) https://issues.apache.org/jira/browse/SOLR-8459

On Tue, Jan 12, 2016 at 3:30 PM Adrien Grand  wrote:

> Sorry Erick for the confusion, it looks like things are good for 5.3.1
> indeed but I meant 5.3.2 above, not 5.3.1. I'll go through commits that
> have been merged to the 5.3 branch and make sure they are on the 5.4 branch
> as well.
>

Re: Documenting Lucene Index Directory File Extensions

[Đạt Cao Mạnh]

Hi Mike,
You can use simpletextcodec and javadoc to get more knowledge about the
Lucene index.
On Aug 30, 2015 10:10 AM, Mike Drob mad...@cloudera.com wrote:

 Is there a document somewhere describing the structure of a lucene index
 directory? Like, at an implementation level, what do all of the extensions
 mean, how do they interact, what file references what, etc. I'm trying to
 discover a human-readable version of this before resorting to code for this.

 Thanks,
 Mike

DocumentsWriterPerThread finishDocument bug?

[Đạt Cao Mạnh]

Hi, currently I'm reading the way Lucene index document and I found this
code and wondering that is it a bug?

DocumentsWriterPerThread.finishDocument(Term delTerm) {
  deleteQueue.add(delTerm, deleteSlice);
  // A point
  deleteSlice.apply(pendingUpdates, numDocsInRAM);
}

In the scenario when DWPT1 finish they deleteQueue.add() but not reach the
apply(). DWPT2 finish they deleteQueue.add() but not reach the apply() too.
So the deleteQueue will be in this form

DWPT1 delTerm node - DWPT2 delTerm node

So when DWPT1 and DWPT2 apply the deleteSlice they will both insert DWPT1
delTerm node, DWPT2 delTerm node to their pendingUpdates.

-- 
*Best regards,*
*Cao Mạnh Đạt*






*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
caomanhdat...@gmail.comHanoi University of Science and TechnologySchool
of information  communication technologyClass : Computer Science K54*

Re: Query needsScores

[Đạt Cao Mạnh]

Hi Uwe,
But I think passing around needsScore flag from searcher, collector, query,
weight, scorer is not a neat solution.

On Mon, Jun 29, 2015 at 5:29 PM, Uwe Schindler u...@thetaphi.de wrote:

 Hi Dat,



 no we cannot remove that. In Lucene 5, Filters are deprecated and will
 disappear completely soon. Filtering is also done by the Query class (in
 fact the backwards compatibility abstract Filter class now extends Query).
 The needsScore is used to tell the Query if the consumer needs scores
 (e.g., if you add a Query using BooleanClause.FILTER to a BooleanQuery).



 Uwe



 -

 Uwe Schindler

 H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Đạt Cao Mạnh [mailto:caomanhdat...@gmail.com]
 *Sent:* Monday, June 29, 2015 12:05 PM
 *To:* dev@lucene.apache.org
 *Subject:* Query needsScores



 In Lucene search, i see the check if(needsScores) in many places. Can we
 devide current queries to Query (that compute score) and Filter (that not
 compute score) and remove needsScores flag?


 --

 *Best regards,*

 *Cao Mạnh Đạt*





 *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
 caomanhdat...@gmail.com*
 *Hanoi University of Science and Technology*
 *School of information  communication technology**Class : Computer
 Science K54*




-- 
*Best regards,*
*Cao Mạnh Đạt*






*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
caomanhdat...@gmail.comHanoi University of Science and TechnologySchool
of information  communication technologyClass : Computer Science K54*

Query needsScores

[Đạt Cao Mạnh]

In Lucene search, i see the check if(needsScores) in many places. Can we
devide current queries to Query (that compute score) and Filter (that not
compute score) and remove needsScores flag?

-- 
*Best regards,*
*Cao Mạnh Đạt*






*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
caomanhdat...@gmail.comHanoi University of Science and TechnologySchool
of information  communication technologyClass : Computer Science K54*

Re: Query needsScores

[Đạt Cao Mạnh]

Hi Andrien,
I mean can we centralise the check of flag in one place create different
classes based on the checking?

On Mon, Jun 29, 2015 at 6:01 PM, Adrien Grand jpou...@gmail.com wrote:

 Actually passing the needsScore flag from collector to Weight is
 exactly why we did this change: collectors can now tell whether they
 need scores or not so that we can optimize query execution. Before we
 did this change, we had to rely on users to build an optimized query
 and for instance put a ConstantScoreQuery(TermFilter) in their
 MUST_NOT clauses instead of passing a simple TermQuery that would load
 norms and freqs even though it was not necessary.

 On Mon, Jun 29, 2015 at 12:36 PM, Đạt Cao Mạnh caomanhdat...@gmail.com
 wrote:
  Hi Uwe,
  But I think passing around needsScore flag from searcher, collector,
 query,
  weight, scorer is not a neat solution.
 
  On Mon, Jun 29, 2015 at 5:29 PM, Uwe Schindler u...@thetaphi.de wrote:
 
  Hi Dat,
 
 
 
  no we cannot remove that. In Lucene 5, Filters are deprecated and will
  disappear completely soon. Filtering is also done by the Query class (in
  fact the backwards compatibility abstract Filter class now extends
 Query).
  The needsScore is used to tell the Query if the consumer needs scores
 (e.g.,
  if you add a Query using BooleanClause.FILTER to a BooleanQuery).
 
 
 
  Uwe
 
 
 
  -
 
  Uwe Schindler
 
  H.-H.-Meier-Allee 63, D-28213 Bremen
 
  http://www.thetaphi.de
 
  eMail: u...@thetaphi.de
 
 
 
  From: Đạt Cao Mạnh [mailto:caomanhdat...@gmail.com]
  Sent: Monday, June 29, 2015 12:05 PM
  To: dev@lucene.apache.org
  Subject: Query needsScores
 
 
 
  In Lucene search, i see the check if(needsScores) in many places. Can we
  devide current queries to Query (that compute score) and Filter (that
 not
  compute score) and remove needsScores flag?
 
 
  --
 
  Best regards,
 
  Cao Mạnh Đạt
 
  D.O.B : 31-07-1991
  Cell: (+84) 946.328.329
  E-mail: caomanhdat...@gmail.com
 
  Hanoi University of Science and Technology
  School of information  communication technology
  Class : Computer Science K54
 
 
 
 
  --
  Best regards,
  Cao Mạnh Đạt
  D.O.B : 31-07-1991
  Cell: (+84) 946.328.329
  E-mail: caomanhdat...@gmail.com
 
  Hanoi University of Science and Technology
  School of information  communication technology
  Class : Computer Science K54



 --
 Adrien

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-- 
*Best regards,*
*Cao Mạnh Đạt*






*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
caomanhdat...@gmail.comHanoi University of Science and TechnologySchool
of information  communication technologyClass : Computer Science K54*

Re: VOTE: RC0 release apache-solr-ref-guide-5.2.pdf

[Đạt Cao Mạnh]

+1 for this reference.

On Fri, Jun 5, 2015 at 3:31 AM, Steve Rowe sar...@gmail.com wrote:

 +1

 Steve

  On Jun 3, 2015, at 1:30 PM, Chris Hostetter hossman_luc...@fucit.org
 wrote:
 
 
  Please VOTE to release these files as the Solr Ref Guide 5.2...
 
 
 https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.2-RC0/
 
 
  NOTE: this vote will be open for a minimum of 72 hours, but i will not
 call this (ref guide) vote to a close until the 5.2.0 code release is also
 successful -- just in case there are any last minute bugs found that
 warrant an update to the ref guide as well.
 
 
 
  -Hoss
  http://www.lucidworks.com/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-- 
*Best regards,*
*Cao Mạnh Đạt*






*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
caomanhdat...@gmail.comHanoi University of Science and TechnologySchool
of information  communication technologyClass : Computer Science K54*