Re: Logging in Solrcloud

2017-12-05 Thread Walter Underwood
+Business Media. > --- > Springer Science+Business Media Deutschland GmbH > Registered Office: Berlin / Amtsgericht Berlin-Charlottenburg, HRB 152987 B > Directors: Derk Haank, Martin Mos, Dr. Ulrich Vest > > ____ > Von: Walter Underwood

Re: Logging in Solrcloud

2017-12-05 Thread Walter Underwood
In 6.5.1, the intra-cluster requests are POST, which makes them easy to distinguish in the request logs. Also, the intra-cluster requests go to a specific core instead of to the collection. So we use the request logs and grep out the GET lines. We are considering fronting every Solr process

Re: Logging in Solrcloud

2017-12-05 Thread Matzdorf, Stefan, Springer SBM DE
To be more precisely and provide some more details, i tried to simplify the problem by using the Solr-examples that were delivered with the solr So i started bin/solr -e cloud, using 2 nodes, 2 shards and replication of 2. To understand the following, it might be important to know, which

Re: Logging in Solrcloud

2017-12-05 Thread Emir Arnautović
Hi Stefan, I am not aware of option to log only client side queries, but I think that you can find workaround with what you currently have. If you take a look at log lines for query that comes from the client and one that is result of querying shards, you will see differences - the most simple

Re: logging in SolrCloud

2017-05-04 Thread Shalin Shekhar Mangar
I'm not a fan of auto-archiving myself and we definitely shouldn't be doing it before checking if an instance is running. Can you please open an issue? On Thu, May 4, 2017 at 12:52 PM, Bernd Fehling wrote: > Hi Shalin, > > sounds like all or nothing method :-) > >

Re: logging in SolrCloud

2017-05-04 Thread Bernd Fehling
Hi Shalin, sounds like all or nothing method :-) How about a short check if an instance is still running and using that log file before moving it to archived? Regards Bernd Am 04.05.2017 um 09:07 schrieb Shalin Shekhar Mangar: > Yes this is expected. On startup old console logs and gc logs are

Re: logging in SolrCloud

2017-05-04 Thread Bernd Fehling
Hi Erik, about 1> I have no core.properties at all, just a clean new installation. - 5 x Zookeeper on 5 different server - 5 x Solr 6.5.1 on 5 different server - uploaded a configset with "bin/solr zk upconfig ..." - started first Solr node with port 8983 of first server - started second Solr

Re: logging in SolrCloud

2017-05-04 Thread Shalin Shekhar Mangar
Yes this is expected. On startup old console logs and gc logs are moved into the archived folder by default. This can be disabled by setting SOLR_LOG_PRESTART_ROTATION=false as a environment variable (search for its usage in bin/solr) but it will also disable all log rotation. On Wed, May 3, 2017

Re: logging in SolrCloud

2017-05-04 Thread Bernd Fehling
Hi Edwin, I'm using Solr 6.5.1 Am 04.05.2017 um 04:35 schrieb Zheng Lin Edwin Yeo: > Which version of Solr are you using? > > I am using Solr 6.4.2, it seems that both nodes are trying to write to the > same archived file. > > > Exception in thread "main" java.nio.file.FileSystemException: >

Re: logging in SolrCloud

2017-05-03 Thread Erick Erickson
Bernd: Do check two things: 1> your core.properties files. Do you have properties set in the core.properties files that could possibly confuse things? 2> when you start your Solr instances, do you define any sysvars that could confuse the archive directories? These are wild shots in the dark

Re: logging in SolrCloud

2017-05-03 Thread Zheng Lin Edwin Yeo
Which version of Solr are you using? I am using Solr 6.4.2, it seems that both nodes are trying to write to the same archived file. Exception in thread "main" java.nio.file.FileSystemException: C:\edwin\solr\server\logs\solr_gc.log.0.current ->

Re: logging in SolrCloud

2017-05-03 Thread Erick Erickson
That does look weird. Does the 7574 console log really get archived or is the 8983 console log archived twice? If 7574 doesn't get moved to the archive, this sounds like a JIRA, I'd go ahead and raise it. Actually either way I think it needs a JIRA. Either the wrong log is getting moved or the