Yikes, yeah it's hard to argue with that.
I'm a little confused because I remember testing this, but maybe it
snuck in at the last minute? In any case, I'll reopen that jira to
fix the check there.
Sorry guys.
Jason
On Wed, Aug 5, 2020 at 9:22 AM Jan Høydahl wrote:
>
> This seems to have
>From time to time I see massive number of threads that have commitScheduler in
>the name of the thread. When this happens, solr is pegging the disk IO and
>querying becomes unusable for a while. I have many collections (240 shards).
>It happens once in a while, I'm really not sure what is
The end point is served by restlet. So, your rules are not going to be
honored. The rules work only if it is served by a Solr request handler
On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski
wrote:
> Hey Noble,
>
> Can you explain what you mean when you say it's not secured? Just for
> those of
Hey Matthew,
Unfortunately, our shard leaders are across multiple nodes thus a single
EBS couldn't work. Did you manage to get around this issue yourself?
Regards,
Ash
On Tue, Aug 11, 2020 at 9:00 PM matthew sporleder
wrote:
> I can already tell you it is EFS that is slow. I had to switch to
> We have 16 shards each approx 30GB - total is ~480GB. I'm also pretty sure
> it's a network issue. Very interesting that you can index 20x the data in
> 15 min!
Not index but backup an index in 15min.
>>> It would also help to ensure your overseer is on a node with a role that
> exempts it
Hello,
We had setup a synchronization between our solr instances on 2 datacenters by
using the CDCR.
until now, every thing worked fine but after an upgrade from solr 7.3 to solr
7.7, we are facing an issue.
Indeed, our tlog files are not deleted even if we see the new values on the
two
I can already tell you it is EFS that is slow. I had to switch to an ebs disk
for backups on a different project because efs couldn't keep up.
> On Aug 10, 2020, at 9:43 PM, Ashwin Ramesh wrote:
>
> Hey Aroop, the general process for our backup is:
> - Connect all machines to an EFS drive
Hi Dominique,
Our issues are similar to the one discussed here.
https://github.com/eclipse/jetty.project/issues/4105
Your views on this.
Thanks,
Mohandoss.
On Tue, Aug 11, 2020 at 7:06 AM Doss wrote:
> Hi Dominique,
>
> Thanks for the response.
>
> I don't think I would use a JVM version 14.
Hi,
This procedure looks fine but it is a little complexe to automatize.
Why not consider backup based on CDCR for Solrcloud or Replication for Solr
standalone ?
For Solrcloud, CDCR can be configured with source and target collections in
the same Solrcloud cluster. The target collection can
CDCR is being deprecated. so I wouldn’t suggest it for the long term.
> On Aug 10, 2020, at 9:33 PM, Ashwin Ramesh wrote:
>
> I would love an answer to this too!
>
> On Fri, Aug 7, 2020 at 12:18 AM Bram Van Dam wrote:
>
>> Hey folks,
>>
>> Been reading up about the various ways of creating
Hi,
Did you disable CDCR buffer ?
solr//cdcr?action=DISABLEBUFFER
You can check with "cdcr?action=STATUS"
Regards
Dominique
Le mar. 11 août 2020 à 10:57, Michel Bamouni a
écrit :
> Hello,
>
>
> We had setup a synchronization between our solr instances on 2 datacenters
> by using the CDCR.
Dominique:
Alternatives are under discussion, there isn’t a recommendation yet.
Erick
> On Aug 11, 2020, at 7:49 AM, Dominique Bejean
> wrote:
>
> I missed that !
> Are you aware about an alternative ?
>
> Regards
>
> Dominique
>
>
> Le mar. 11 août 2020 à 13:15, Erick Erickson a
>
An idea could be use autoscaling API in order to add a PULL replica for
each shard located in one or more low resource backup dedicated nodes in
separate hardware.
However, we need to exclude these "PULL backup replica" from searches.
Unfortunately, I am not aware of this possibility.
For better
I missed that !
Are you aware about an alternative ?
Regards
Dominique
Le mar. 11 août 2020 à 13:15, Erick Erickson a
écrit :
> CDCR is being deprecated. so I wouldn’t suggest it for the long term.
>
> > On Aug 10, 2020, at 9:33 PM, Ashwin Ramesh
> wrote:
> >
> > I would love an answer to
Dear contributors,
As part of a research team from Università della Svizzera italiana
(Switzerland) and University of Sannio (Italy), we have analyzed refactoring
pull requests in apache/lucene-solr repository and are looking for developers
for a short 5-10 min survey
Hi all,
The end-point for Managed resources is not secured. So it needs to be
fixed/eliminated.
I would like to know what is the level of adoption for that feature
and if it is a critical feature for users.
Another possibility is to offer a replacement for the feature using a
different API
Your
Hi all,
Is it possible to have multiple "df" fields? (We think the answer is no
because our experiments did not work when adding multiple "df" values to
solrconfig.xml -- but we just wanted to double check with those who know
better.) The reason we would like to do this is that we have two main
why not use a copyfield for indexing?
On Tue, Aug 11, 2020 at 9:59 AM Edward Turner wrote:
> Hi all,
>
> Is it possible to have multiple "df" fields? (We think the answer is no
> because our experiments did not work when adding multiple "df" values to
> solrconfig.xml -- but we just wanted to
Hi David,
We tried using copyfields, and we can get this to work, but it's not
exactly what we want because we need to use a common type. E.g.,
Then if our "df" is specified as the "content" field, we can search over
I can't remember if field aliasing works with df but it may be worth a try:
https://lucene.apache.org/solr/guide/8_1/the-extended-dismax-query-parser.html#field-aliasing-using-per-field-qf-overrides
Another example:
Hey Noble,
Can you explain what you mean when you say it's not secured? Just for
those of us who haven't been following the discussion so far? On the
surface of things users taking advantage of our RuleBasedAuth plugin
can secure this API like they can any other HTTP API. Or are you
talking
Have you explored edismax?
> On Aug 11, 2020, at 10:34 AM, Alexandre Rafalovitch
> wrote:
>
> I can't remember if field aliasing works with df but it may be worth a try:
>
>
Hey Abhijit,
The information you provided isn't really enough for anyone else on
the mailing list to debug the problem. If you'd like help, please
provide some more information.
Good places to start would be: what is the query, what does Solr tell
you when you add a "debug=timing" parameter to
On 11/08/2020 13:15, Erick Erickson wrote:
> CDCR is being deprecated. so I wouldn’t suggest it for the long term.
Ah yes, thanks for pointing that out. That makes Dominique's alternative
less attractive. I guess I'll stick to my original proposal!
Thanks Erick :-)
- Bram
24 matches
Mail list logo
