I know that we have never set the schedule parameter to 1 millisecond. We
have specified either 100 or 1000. I wondered why it was writing so
frequently. I suspect a bug somewhere

However, we will have multiple collections using cdcr, and in some cases
the source collection will have multiple targets.

I understand your point about the request handler, I think being able to
specify messaging levels for specific handlers is essential

On Mon, Jan 9, 2017 at 10:07 PM, Shawn Heisey <apa...@elyograg.org> wrote:

> On 12/22/2016 8:10 AM, Webster Homer wrote:
> > While testing CDCR I found that it is writing tons of log messages per
> > second. Example:
> > 2016-12-21 23:24:41.652 INFO  (qtp110456297-13) [c:sial-catalog-material
> > s:shard1 r:core_node1 x:sial-catalog-material_shard1_replica1]
> > o.a.s.c.S.Request [sial-catalog-material_shard1_replica1]  webapp=/solr
> > path=/cdcr params={qt=/cdcr&action=BOOTSTRAP_STATUS&wt=javabin&
> version=2}
> > status=0 QTime=0
> > 2016-12-21 23:24:41.653 INFO  (qtp110456297-18) [c:sial-catalog-material
> > s:shard1 r:core_node1 x:sial-catalog-material_shard1_replica1]
> > o.a.s.c.S.Request [sial-catalog-material_shard1_replica1]  webapp=/solr
> > path=/cdcr params={qt=/cdcr&action=BOOTSTRAP_STATUS&wt=javabin&
> version=2}
> > status=0 QTime=0
>
> I hadn't looked closely at the messages you were seeing in your logs
> until now.
>
> These messages are *request* logging.  This is the same code path that
> logs every query -- it's not specific to CDCR.  It's just logging all
> the requests that Solr is receiving.  If this log message were changed
> to DEBUG, then Solr would not log queries by default.  A large number of
> Solr users want that logging.
>
> I think that you could probably avoid seeing these logs by configuring
> log4j to not log things tagged
> asorg.apache.solr.core.SolrCore.Request(even though it's not a real
> class, I think log4j can still configure it) ... but then you wouldn't
> get your queries logged either.
>
> In order to not log these particular messages, but still log queries and
> other requests, the request logging code will need to have a way to
> specify that certain messages should not be logged.  This might be
> something thatcould beconfigurable at the request handler definition
> level -- put something in the requestHandler configuration (for /cdcr in
> this case) that tells it to skip logging.  That seems like a good
> feature to have.
>
> After looking at the CDCR configuration page in the reference guide, I
> might have a little more insight.  You're getting one of these logs
> every 1-2 milliseconds ... so it sounds like you have configured the
> CDCR with a schedule of one millisecond.  The default value for the
> replicator schedule is is ten milliseconds, and the update log
> synchronizer defaults to a full minute.  I'm guessing that CDCR is not
> designed to have such a low schedule value.  I would personally
> configure the replicator schedule even higher than the default --
> network latency between Internet locations is often longer than ten
> milliseconds.
>
> Thanks,
> Shawn
>
>

-- 


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, 
you must not copy this message or attachment or disclose the contents to 
any other person. If you have received this transmission in error, please 
notify the sender immediately and delete the message and any attachment 
from your system. Merck KGaA, Darmstadt, Germany and any of its 
subsidiaries do not accept liability for any omissions or errors in this 
message which may arise as a result of E-Mail-transmission or for damages 
resulting from any unauthorized changes of the content of this message and 
any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its 
subsidiaries do not guarantee that this message is free of viruses and does 
not accept liability for any damages caused by any virus transmitted 
therewith.

Click http://www.emdgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.

Reply via email to