RE: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any tests with Java 13 and the new ZGC?

[Vassil Velichkov (Sensika)]

>> App Log Sample Entries
[2019-10-15 00:01:06] PRD-01-WEB-04.ERROR [0.000580]: search -> SOLR Exception 
[1/3]: queryId=[85e6a7d6f2a9f7e08fc438c862e4df9b], responseHttpCode=[500], 
solrResponseCode=[500], 
solrMessage=[org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://172.18.1.206:8983/solr/post], 
SOLR Shards: Array
(
[0] => 172.18.1.191:8983/solr/post
[1] => 172.18.1.206:8983/solr/post
[2] => 172.18.1.198:8983/solr/post
)


Cheers,
Vassil

-Original Message-
From: Shawn Heisey  
Sent: Monday, October 14, 2019 5:22 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any 
tests with Java 13 and the new ZGC?

On 10/14/2019 7:18 AM, Vassil Velichkov (Sensika) wrote:
>>>>>> After the migration from 6.x to 7.6 we kept the default GC for a couple 
>>>>>> of weeks, than we've started experimenting with G1 and we've managed to 
>>>>>> achieve less frequent OOM crashes, but not by much.

Changing your GC settings will never prevent OOMs.  The only way to prevent 
them is to either increase the resource that's running out or reconfigure the 
program to use less of that resource.

>>>>>> As I explained in my previous e-mail, the unused filterCache entries are 
>>>>>> not discarded, even after a new SolrSearcher is started. The Replicas 
>>>>>> are synced with the Masters every 5 minutes, the filterCache is 
>>>>>> auto-warmed and the JVM heap utilization keeps going up. Within 1 to 2 
>>>>>> hours a 64GB heap is being exhausted. The GC log entries clearly show 
>>>>>> that there are more and more humongous allocations piling up.

While it is true that the generation-specific collectors for G1 do not clean up 
humungous allocations from garbage, eventually Java will perform a full GC, 
which will be slow, but should clean them up.  If a full GC is not cleaning 
them up, that's a different problem, and one that I would suspect is actually a 
problem with your installation.  We have had memory leak bugs in Solr, but I am 
not aware of any that are as serious as your observations suggest.

You could be running into a memory leak ... but I really doubt that it is 
directly related to the filterCache or the humungous allocations. 
Upgrading to the latest release that you can would be advisable -- the latest 
7.x version would be my first choice, or you could go all the way to 8.2.0.

Are you running completely stock Solr, or have you added custom code? 
One of the most common problems with custom code is leaking searcher objects, 
which will cause Java to retain the large cache entries.  We have seen problems 
where one Solr version will work perfectly with custom code, but when Solr is 
upgraded, the custom code has memory leaks.

>>>>>>> We have a really stressful use-case: a single user opens a live-report 
>>>>>>> with 20-30 widgets, each widget performs a Solr Search or facet 
>>>>>>> aggregations, sometimes with 5-15 complex filter queries attached to 
>>>>>>> the main query, so the end results are visualized as pivot charts. So, 
>>>>>>> one user could trigger hundreds of queries in a very short period of 
>>>>>>> time and when we have several analysts working on the same time-period, 
>>>>>>> we usually end-up with OOM. This logic used to work quite well on Solr 
>>>>>>> 6.x. The only other difference that comes to my mind is that with Solr 
>>>>>>> 7.6 we've started using DocValues. I could not find documentation about 
>>>>>>> DocValues memory consumption, so it might be related.

For cases where docValues are of major benefit, which is primarily facets and 
sorting, Solr will use less memory with docValues than it does with indexed 
terms.  Adding docValues should not result in a dramatic increase in memory 
requirements, and in many cases, should actually require less memory.

>>>>>>> Yep, but I plan to generate some detailed JVM trace-dumps, so we could 
>>>>>>> analyze which class / data structure causes the OOM. Any 
>>>>>>> recommendations about what tool to use for a detailed JVM dump?

Usually the stacktrace itself is not helpful in diagnosing OOMs -- because the 
place where the error is thrown can be ANY allocation, not necessarily the one 
that is the major resource hog.

What I'm interested in here is the message immediately after the OOME, not the 
stacktrace.  Which I'll admit is slightly odd, because for many problems I *am* 
interested in the stacktrace.  OutOfMemoryError is one situation where the 
stacktrace is

RE: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any tests with Java 13 and the new ZGC?

[Vassil Velichkov (Sensika)]

Hi Shawn,

My answers are in-line below...

Cheers,
Vassil

-Original Message-
From: Shawn Heisey  
Sent: Monday, October 14, 2019 3:56 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any 
tests with Java 13 and the new ZGC?

On 10/14/2019 6:18 AM, Vassil Velichkov (Sensika) wrote:
> We have 1 x Replica with 1 x Solr Core per JVM and each JVM runs in a 
> separate VMware VM.
> We have 32 x JVMs/VMs in total, containing between 50M to 180M documents per 
> replica/core/JVM.

With 180 million documents, each filterCache entry will be 22.5 megabytes in 
size.  They will ALL be this size.

>>>>> Ops, I didn't know that, but this makes the things even worse. By looking 
>>>>> at the GC log, it seems evicted entries are never discarded.

> In our case most filterCache entities (maxDoc/8 + overhead) are typically 
> more than 16MB, which is more than 50% of the max setting for 
> "XX:G1HeapRegionSize" (which is 32MB). That's why I am so interested in Java 
> 13 and ZGC, because ZGC does not have this weird limitation and collects even 
> _large_ garbage pieces :-). We have almost no documentCache or queryCache 
> entities.

I am not aware of any Solr testing with the new garbage collector.  I'm 
interested in knowing whether it does a better job than CMS and G1, but do not 
have any opportunities to try it.

>>>>> Currently we have some 2TB free RAM on the cluster, so I guess we could 
>>>>> test it in the next coming days. The plan is to re-index at least 2B 
>>>>> documents in a separate cluster and stress-test the new cluster with real 
>>>>> production data and real production code with Java 13 and ZGC.

Have you tried letting Solr use its default garbage collection settings instead 
of G1?  Have you tried Java 11?  Java 9 is one of the releases without long 
term support, so as Erick says, it is not recommended.

>>>>> After the migration from 6.x to 7.6 we kept the default GC for a couple 
>>>>> of weeks, than we've started experimenting with G1 and we've managed to 
>>>>> achieve less frequent OOM crashes, but not by much.

> By some time tonight all shards will be rebalanced (we've added 6 more) and 
> will contain up to 100-120M documents (14.31MB + overhead should be < 16MB), 
> so hopefully this will help us to alleviate the OOM crashes.

It doesn't sound to me like your filterCache can cause OOM.  The total size of 
256 filterCache entries that are each 22.5 megabytes should be less than 6GB, 
and I would expect the other Solr caches to be smaller.

>>>>> As I explained in my previous e-mail, the unused filterCache entries are 
>>>>> not discarded, even after a new SolrSearcher is started. The Replicas are 
>>>>> synced with the Masters every 5 minutes, the filterCache is auto-warmed 
>>>>> and the JVM heap utilization keeps going up. Within 1 to 2 hours a 64GB 
>>>>> heap is being exhausted. The GC log entries clearly show that there are 
>>>>> more and more humongous allocations piling up. 
 
If you are hitting OOMs, then some other aspect of your setup is the reason 
that's happening.  I would not normally expect a single core with
180 million documents to need more than about 16GB of heap, and 31GB should 
definitely be enough.  Hitting OOM with the heap sizes you have described is 
very strange.

>>>>>> We have a really stressful use-case: a single user opens a live-report 
>>>>>> with 20-30 widgets, each widget performs a Solr Search or facet 
>>>>>> aggregations, sometimes with 5-15 complex filter queries attached to the 
>>>>>> main query, so the end results are visualized as pivot charts. So, one 
>>>>>> user could trigger hundreds of queries in a very short period of time 
>>>>>> and when we have several analysts working on the same time-period, we 
>>>>>> usually end-up with OOM. This logic used to work quite well on Solr 6.x. 
>>>>>> The only other difference that comes to my mind is that with Solr 7.6 
>>>>>> we've started using DocValues. I could not find documentation about 
>>>>>> DocValues memory consumption, so it might be related.

Perhaps the root cause of your OOMs is not heap memory, but some other system 
resource.  Do you have log entries showing the stacktrace on the OOM?

>>>>>> Yep, but I plan to generate some detailed JVM trace-dumps, so we could 
>>>>>> analyze which class / data structure causes the OOM. Any recommendations 
>>>>>> about what tool to use for a detailed JVM dump? 
Also, not sure if I could send attachments to the mailing list, but there must 
be a way to share logs...?

Thanks,
Shawn

RE: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any tests with Java 13 and the new ZGC?

[Vassil Velichkov (Sensika)]

Hi Erick,

We have 1 x Replica with 1 x Solr Core per JVM and each JVM runs in a separate 
VMware VM.
We have 32 x JVMs/VMs in total, containing between 50M to 180M documents per 
replica/core/JVM.
In our case most filterCache entities (maxDoc/8 + overhead) are typically more 
than 16MB, which is more than 50% of the max setting for "XX:G1HeapRegionSize" 
(which is 32MB). That's why I am so interested in Java 13 and ZGC, because ZGC 
does not have this weird limitation and collects even _large_ garbage pieces 
:-). We have almost no documentCache or queryCache entities.

By some time tonight all shards will be rebalanced (we've added 6 more) and 
will contain up to 100-120M documents (14.31MB + overhead should be < 16MB), so 
hopefully this will help us to alleviate the OOM crashes.

Cheers,
Vassil


-Original Message-
From: Erick Erickson  
Sent: Monday, October 14, 2019 3:03 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any 
tests with Java 13 and the new ZGC?

The filterCache isn’t a single huge allocation, it’s made up of _size_ entries, 
each individual entry shouldn’t be that big, each entry should cap around 
maxDoc/8 bytes + some overhead.

I just scanned the e-mail, I’m not clear how many _replicas_ per JVM you have, 
nor how many JVMs per server you’re running. One strategy to deal with large 
heaps if you have a lot of replicas is to run multiple JVMs, each with a 
smaller heap.

One peculiarity of heaps is that at 32G, one must use long pointers, so a 32G 
heap actually has less available memory than a 31G heap if many of the objects 
are small.


> On Oct 14, 2019, at 7:00 AM, Vassil Velichkov (Sensika) 
>  wrote:
> 
> Thanks Jörn,
> 
> Yep, we are rebalancing the cluster to keep up to ~100M documents per shard, 
> but that's not quite optimal in our use-case.
> 
> We've tried with various ratios between JVM Heap / OS RAM (up to 128GB / 
> 256GB) and we have the same Java Heap OOM crashes.
> For example, a BitSet of 160M documents is > 16MB and when we look at the G1 
> logs, it seems it never discards the humongous allocations, so they keep 
> piling. Forcing a full-garbage collection is just not practical - it takes 
> forever and the shard is not usable. Even when a new Searcher is started 
> (every several minutes) the old large filterCache entries are not freed and 
> sooner or later the JVM crashes.
> 
> On the other hand ZGC has a completely different architecture and does not 
> have the hard-coded threshold of 16MB for *humongous allocations*:
> https://wiki.openjdk.java.net/display/zgc/Main
> 
> Anyway, we will be probably testing Java 13 and ZGC with the real data, we 
> just have to reindex 30+ shards to new Solr servers, which will take a couple 
> of days :-)
> 
> Cheers,
> Vassil
> 
> -Original Message-
> From: Jörn Franke  
> Sent: Monday, October 14, 2019 1:47 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any 
> tests with Java 13 and the new ZGC?
> 
> I would try JDK11 - it works much better than JDK9 in general. 
> 
> I don‘t think JDK13 with ZGC will bring you better results. There seems to be 
> sth strange with the JDk version or Solr version and some settings. 
> 
> Then , make sure that you have much more free memory for the os cache than 
> the heap. Nearly 100 gb for Solr heap sounds excessive. Try to reduce it to 
> much less.
> 
> Try the default options of Solr and use the latest 7.x version or 8.x version 
> of Solr.
> 
> Additionally you can try to shard more.
> 
>> Am 14.10.2019 um 19:19 schrieb Vassil Velichkov (Sensika) 
>> :
>> 
>> Hi Everyone,
>> 
>> Since we’ve upgraded our cluster (legacy sharding) from Solr 6.x to Solr 7.6 
>> we have frequent OOM crashes on specific nodes.
>> 
>> All investigations (detailed below) lead to a hard-coded limitation in the 
>> G1 garbage collector. The Java Heap is exhausted due to too many filterCache 
>> allocations that are never discarded by the G1.
>> 
>> Our hope is to use Java 13 with the new ZGC, which is specifically designed 
>> for large heap-sizes, and supposedly would handle and dispose larger 
>> allocations. The Solr release notes claim that Solr 7.6 builds are tested 
>> with Java 11 / 12 / 13 (pre-release).
>> Does anyone use Java 13 in production and has experience with the new ZGC 
>> and large heap sizes / large document sets of more than 150M documents per 
>> shard?
>> 
>>>>>>>>>>> Some background information and reference to the possible 
>>>>>>>>>>> root-cause, described by Shawn Heisey in Solr 1.4 documenta

RE: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any tests with Java 13 and the new ZGC?

[Vassil Velichkov (Sensika)]

Thanks Jörn,

Yep, we are rebalancing the cluster to keep up to ~100M documents per shard, 
but that's not quite optimal in our use-case.

We've tried with various ratios between JVM Heap / OS RAM (up to 128GB / 256GB) 
and we have the same Java Heap OOM crashes.
For example, a BitSet of 160M documents is > 16MB and when we look at the G1 
logs, it seems it never discards the humongous allocations, so they keep 
piling. Forcing a full-garbage collection is just not practical - it takes 
forever and the shard is not usable. Even when a new Searcher is started (every 
several minutes) the old large filterCache entries are not freed and sooner or 
later the JVM crashes.

On the other hand ZGC has a completely different architecture and does not have 
the hard-coded threshold of 16MB for *humongous allocations*:
https://wiki.openjdk.java.net/display/zgc/Main

Anyway, we will be probably testing Java 13 and ZGC with the real data, we just 
have to reindex 30+ shards to new Solr servers, which will take a couple of 
days :-)

Cheers,
Vassil

-Original Message-
From: Jörn Franke  
Sent: Monday, October 14, 2019 1:47 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any 
tests with Java 13 and the new ZGC?

I would try JDK11 - it works much better than JDK9 in general. 

I don‘t think JDK13 with ZGC will bring you better results. There seems to be 
sth strange with the JDk version or Solr version and some settings. 

Then , make sure that you have much more free memory for the os cache than the 
heap. Nearly 100 gb for Solr heap sounds excessive. Try to reduce it to much 
less.

Try the default options of Solr and use the latest 7.x version or 8.x version 
of Solr.

Additionally you can try to shard more.

> Am 14.10.2019 um 19:19 schrieb Vassil Velichkov (Sensika) 
> :
> 
> Hi Everyone,
> 
> Since we’ve upgraded our cluster (legacy sharding) from Solr 6.x to Solr 7.6 
> we have frequent OOM crashes on specific nodes.
> 
> All investigations (detailed below) lead to a hard-coded limitation in the G1 
> garbage collector. The Java Heap is exhausted due to too many filterCache 
> allocations that are never discarded by the G1.
> 
> Our hope is to use Java 13 with the new ZGC, which is specifically designed 
> for large heap-sizes, and supposedly would handle and dispose larger 
> allocations. The Solr release notes claim that Solr 7.6 builds are tested 
> with Java 11 / 12 / 13 (pre-release).
> Does anyone use Java 13 in production and has experience with the new ZGC and 
> large heap sizes / large document sets of more than 150M documents per shard?
> 
>>>>>>>>>> Some background information and reference to the possible 
>>>>>>>>>> root-cause, described by Shawn Heisey in Solr 1.4 documentation >>>>>
> 
> Our current setup is as follows:
> 
> 1.   All nodes are running on VMware 6.5 VMs with Debian 9u5 / Java 9 / 
> Solr 7.6
> 
> 2.   Each VM has 6 or 8 x vCPUs, 128GB or 192GB RAM (50% for Java Heap / 
> 50% for OS) and 1 x Solr Core with 80M to 160M documents, NO stored fields, 
> DocValues ON
> 
> 3.   The only “hot” and frequently used cache is filterCache, configured 
> with the default value of 256 entries. If we increase the setting to 512 or 
> 1024 entries, we are getting 4-5 times better hit-ratio, but the OOM crashes 
> become too frequent.
> 
> 4.   Regardless of the Java Heap size (we’ve tested with even larger 
> heaps and VM sizing up to 384GB), all nodes that have approx. more than 
> 120-130M documents crash with OOM under heavy load (hundreds of simultaneous 
> searches with a variety of Filter Queries).
> 
> FilterCache is really frequently used and some of the BitSets are spanning 
> across 80-90% of the Docset of each shard, so in many cases the FC entries 
> become larger than 16MB. We believe we’ve pinpointed the problem to the G1 
> Garbage Collector and the hard-coded limit for "-XX:G1HeapRegionSize", which 
> allows setting a maximum of 32MB, regardless if it is auto-calculated or set 
> manually in the JVM startup options. The JVM memory allocation algorithm 
> tracks every memory allocation request and if the request exceeds 50% of 
> G1HeapRegionSize, it is considered humongous allocation (he-he, extremely 
> large allocation in 2019?!?), so it is not scanned and evaluated during 
> standard garbage collection cycles. Unused humongous allocations are 
> basically freed only during Full Garbage Collection cycles, which are never 
> really invoked by the G1 garbage collector, before it is too late and the JVM 
> crashes with OOM.
> 
> Now we are rebalancing the cluster to have up to 100-120M  documents per 
> shard, following and ancient, but probably still 

Solr 7.6 frequent OOM with Java 9, G1 and large heap sizes - any tests with Java 13 and the new ZGC?

[Vassil Velichkov (Sensika)]

Hi Everyone,

Since we’ve upgraded our cluster (legacy sharding) from Solr 6.x to Solr 7.6 we 
have frequent OOM crashes on specific nodes.

All investigations (detailed below) lead to a hard-coded limitation in the G1 
garbage collector. The Java Heap is exhausted due to too many filterCache 
allocations that are never discarded by the G1.

Our hope is to use Java 13 with the new ZGC, which is specifically designed for 
large heap-sizes, and supposedly would handle and dispose larger allocations. 
The Solr release notes claim that Solr 7.6 builds are tested with Java 11 / 12 
/ 13 (pre-release).
Does anyone use Java 13 in production and has experience with the new ZGC and 
large heap sizes / large document sets of more than 150M documents per shard?

> Some background information and reference to the possible root-cause, 
> described by Shawn Heisey in Solr 1.4 documentation >

Our current setup is as follows:

1.   All nodes are running on VMware 6.5 VMs with Debian 9u5 / Java 9 / 
Solr 7.6

2.   Each VM has 6 or 8 x vCPUs, 128GB or 192GB RAM (50% for Java Heap / 
50% for OS) and 1 x Solr Core with 80M to 160M documents, NO stored fields, 
DocValues ON

3.   The only “hot” and frequently used cache is filterCache, configured 
with the default value of 256 entries. If we increase the setting to 512 or 
1024 entries, we are getting 4-5 times better hit-ratio, but the OOM crashes 
become too frequent.

4.   Regardless of the Java Heap size (we’ve tested with even larger heaps 
and VM sizing up to 384GB), all nodes that have approx. more than 120-130M 
documents crash with OOM under heavy load (hundreds of simultaneous searches 
with a variety of Filter Queries).

FilterCache is really frequently used and some of the BitSets are spanning 
across 80-90% of the Docset of each shard, so in many cases the FC entries 
become larger than 16MB. We believe we’ve pinpointed the problem to the G1 
Garbage Collector and the hard-coded limit for "-XX:G1HeapRegionSize", which 
allows setting a maximum of 32MB, regardless if it is auto-calculated or set 
manually in the JVM startup options. The JVM memory allocation algorithm tracks 
every memory allocation request and if the request exceeds 50% of 
G1HeapRegionSize, it is considered humongous allocation (he-he, extremely large 
allocation in 2019?!?), so it is not scanned and evaluated during standard 
garbage collection cycles. Unused humongous allocations are basically freed 
only during Full Garbage Collection cycles, which are never really invoked by 
the G1 garbage collector, before it is too late and the JVM crashes with OOM.

Now we are rebalancing the cluster to have up to 100-120M  documents per shard, 
following and ancient, but probably still valid limitation suggested in Solr 
1.4 documentation by Shawn 
Heisey: “If you 
have an index with about 100 million documents in it, you'll want to use a 
region size of 32MB, which is the maximum possible size. Because of this 
limitation of the G1 collector, we recommend always keeping a Solr index below 
a maxDoc value of around 100 to 120 million.”

Cheers,
Vassil Velichkov

Problem with confirming e-mail address for joining the user mailing list

[Vassil Velichkov (Sensika)]

Hi,

I am trying to join the Solr User mailing list, but I can’t confirm my e-mail 
address – following the instructions in the “Confirm subscribe” e-mail, I 
replied to the confirmation request e-mail, but I have been getting 
“Undeliverable” receipts since yesterday. In short - that’s what my mail server 
returns as an error:
Remote Server returned '501 Syntax error - Badly formatted address.'

Please, find attached both the “Undeliverable: Confirmation” and the request 
for confirmation e-mails.

Is there any other way to confirm my e-mail and my willingness to join the Solr 
User mailing list?

Best regards,
Vassil Velichkov
CTO, Sensika Technologies


--- Begin Message ---
Delivery has failed to these recipients or groups:

solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org
 
(solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org)<mailto:solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov%3dsensika@lucene.apache.org>
A problem occurred while delivering this message to this email address. Try 
sending this message again. If the problem continues, please contact your 
helpdesk.



The following organization rejected your message: Requested.







Diagnostic information for administrators:

Generating server: DGM-XCH-01.grammasystems.com


solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org
Requested
Remote Server returned '501 Syntax error - Badly formatted address.'


Original message headers:

Received: from DGM-XCH-01.grammasystems.com (10.0.0.33) by
 DGM-XCH-01.grammasystems.com (10.0.0.33) with Microsoft SMTP Server (TLS) id
 15.0.1367.3; Thu, 18 Jul 2019 13:24:01 +0300
Received: from DGM-XCH-01.grammasystems.com ([::1]) by
 DGM-XCH-01.grammasystems.com ([::1]) with mapi id 15.00.1367.000; Thu, 18 Jul
 2019 13:24:01 +0300
From: "Vassil Velichkov (Sensika)" 
To:

"solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org"


Subject: Confirmation
Thread-Topic: Confirmation
Thread-Index: AdU9UupBF+ZXBemERqeUzQFTC/Cflw==
Date: Thu, 18 Jul 2019 10:24:01 +
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [91.209.8.202]
Content-Type: multipart/alternative;
boundary="_000_dc2bbdb7d5604ed5b90c7f1c1e826127DGMXCH01grammasystemsco_"
MIME-Version: 1.0

Reporting-MTA: dns; DGM-XCH-01.grammasystems.com

Final-recipient: RFC822;
 solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika.com@lucene.apache.org
Action: failed
Status: 5.0.0
Remote-MTA: dns; Requested
X-Supplementary-Info: 

--- Begin Message ---

--- End Message ---
--- End Message ---
--- Begin Message ---
Hi! This is the ezmlm program. I'm managing the
solr-user@lucene.apache.org mailing list.

I'm working for my owner, who can be reached
at solr-user-ow...@lucene.apache.org.

To confirm that you would like

   vassil.velich...@sensika.com

added to the solr-user mailing list, please send
a short reply to this address:

   
solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org

Usually, this happens when you just hit the "reply" button.
If this does not work, simply copy the address and paste it into
the "To:" field of a new message.

or click here:

mailto:solr-user-sc.1563444943.hlpklibaogainglfpegm-vassil.velichkov=sensika@lucene.apache.org

This confirmation serves two purposes. First, it verifies that I am able
to get mail through to you. Second, it protects you in case someone
forges a subscription request in your name.

Please note that ALL Apache dev- and user- mailing lists are publicly
archived.  Do familiarize yourself with Apache's public archive policy at

http://www.apache.org/foundation/public-archives.html

prior to subscribing and posting messages to solr-user@lucene.apache.org.
If you're not sure whether or not the policy applies to this mailing list,
assume it does unless the list name contains the word "private" in it.

Some mail programs are broken and cannot handle long addresses. If you
cannot reply to this request, instead send a message to
 and put the
entire address listed above into the "Subject:" line.


--- Administrative commands for the solr-user list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   

To remove your address from the list, send a message to:
   

Send mail to the following for info and FAQ for this list:
   
   

Similar addresses exist for the digest list:
   
   

To get messages 123 through 145 (a maximum of 100 per request), mail:
   

To get an index with subject and author for messages 123-45