Very long young generation stop the world GC pause
Hi Shawn, Thanks a lot for your response! I'll use this mail thread on tracking the issue in JIRA https://issues.apache.org/jira/browse/SOLR-9828 . -- View this message in context: http://lucene.472066.n3.nabble.com/Very-long-young-generation-stop-the-world-GC-pause-tp4308911.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Issue
Hi Monti,
As pointed out there is a huge gap of no information. There are two primary
possibilities. One is that something about your resources is depleted. As
Shawn has pointed out... watch them as you start up. Two, Solr is somehow
locked or waiting on something. Since there is no information at the INFO
level you can either throw your logs into DEBUG level and pray to god you
see something relevant in the noise. Or, you can run a thread dump after
you've hit your gap in time and see what the server is doing at that
moment. My recommendation is to do the latter. I'd also wonder about that 0
cores found entry as well.
Greg
On Dec 7, 2016 3:02 AM, "Monti Chandra" wrote:
> Hello team,
> I am working on solr version to 6.2.1. It was working so nice for the first
> 20 days and now the server is restarting very slow(15-20 min).
> Please get the hardware specs of my system below:
> Linux version 3.10.0-327.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc
> version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )
> kernel-3.10.0-327.el7.x86_64
> It is working fine when i am taking solr directory to another server of
> same configuartion.
>
> As I am using 6.2.1 basically, So i have downloaded the fresh
> solr-6.2.1(without any collection) and try to start the same but the server
> is not able to start effectively. please get the log below:
>
> 0INFO (main) [ ] o.e.j.u.log Logging initialized @257ms
> 131 INFO (main) [ ] o.e.j.s.Server jetty-9.3.8.v20160314
> 146 INFO (main) [ ] o.e.j.d.p.ScanningAppProvider Deployment monitor
> [file:///root/temp/solr-6.2.1/server/contexts/] at interval 0
> 311 INFO (main) [ ] o.e.j.w.StandardDescriptorProcessor NO JSP Support
> for /solr, did not find org.apache.jasper.servlet.JspServlet
> 320 WARN (main) [ ] o.e.j.s.SecurityHandler
> ServletContext@o.e.j.w.WebAppContext@5383967b{/solr,
> file:///root/temp/solr-6.2.1/server/solr-webapp/webapp/,
> STARTING}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
> has uncovered http methods for path: /
> 327 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> SolrDispatchFilter.init(): WebAppClassLoader=1465085305@57536d79
> 340 INFO (main) [ ] o.a.s.c.SolrResourceLoader JNDI not configured for
> solr (NoInitialContextEx)
> 340 INFO (main) [ ] o.a.s.c.SolrResourceLoader using system property
> solr.solr.home: /root/temp/solr-6.2.1/server/solr
> 340 INFO (main) [ ] o.a.s.c.SolrResourceLoader new SolrResourceLoader
> for directory: '/root/temp/solr-6.2.1/server/solr'
> 340 INFO (main) [ ] o.a.s.c.SolrResourceLoader JNDI not configured for
> solr (NoInitialContextEx)
> 340 INFO (main) [ ] o.a.s.c.SolrResourceLoader using system property
> solr.solr.home: /root/temp/solr-6.2.1/server/solr
> 345 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading container
> configuration from /root/temp/solr-6.2.1/server/solr/solr.xml
> 402 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Config-defined core
> root directory: /root/temp/solr-6.2.1/server/solr
> 424 INFO (main) [ ] o.a.s.c.CoreContainer New CoreContainer 1663619914
> 425 INFO (main) [ ] o.a.s.c.CoreContainer Loading cores into
> CoreContainer [instanceDir=/root/temp/solr-6.2.1/server/solr]
> 425 WARN (main) [ ] o.a.s.c.CoreContainer Couldn't add files from
> /root/temp/solr-6.2.1/server/solr/lib to classpath:
> /root/temp/solr-6.2.1/server/solr/lib
> 434 INFO (main) [ ] o.a.s.h.c.HttpShardHandlerFactory created with
> socketTimeout : 60,connTimeout : 6,maxConnectionsPerHost :
> 20,maxConnections : 1,corePoolSize : 0,maximumPoolSize :
> 2147483647,maxThreadIdleTime : 5,sizeOfQueue : -1,fairnessPolicy :
> false,useRetries : false,connectionsEvictorSleepDelay :
> 5000,maxConnectionIdleTime : 4,
> 592 INFO (main) [ ] o.a.s.u.UpdateShardHandler Creating
> UpdateShardHandler HTTP client with params:
> socketTimeout=60&connTimeout=6&retry=true
> 594 INFO (main) [ ] o.a.s.l.LogWatcher SLF4J impl is
> org.slf4j.impl.Log4jLoggerFactory
> 594 INFO (main) [ ] o.a.s.l.LogWatcher Registering Log Listener [Log4j
> (org.slf4j.impl.Log4jLoggerFactory)]
> 596 INFO (main) [ ] o.a.s.c.CoreContainer Security conf doesn't exist.
> Skipping setup for authorization module.
> 596 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin
> used.
> 127902 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
> definitions underneath /root/temp/solr-6.2.1/server/solr
> 127906 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
> definitions
> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> user.dir=/root/temp/solr-6.2.1/server
> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> SolrDispatchFilter.init() done
> 127918 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
> o.e.j.w.WebAppContext@5383967b
> {/solr,file:///root/temp/solr-6.2.1/server/solr-webapp/
> webapp/,AVAILABLE}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
> 127926 INFO (main) [ ] o.e.j.s.ServerConnector Sta
Re: Solr node not found in ZK live_nodes
That already happens. The ZK client itself will reconnect when it can and trigger everything to be setup like when the cluster first starts up, including a live node and leader election, etc. You may have hit a bug or something else missing from this conversation, but reconnecting after losing the ZK connection is a basic feature from day one. Mark On Wed, Dec 7, 2016 at 12:34 AM Manohar Sripada wrote: > Thanks Erick! Should I create a JIRA issue for the same? > > Regarding the logs, I have changed the log level to WARN. That may be the > reason, I couldn't get anything from it. > > Thanks, > Manohar > > On Tue, Dec 6, 2016 at 9:58 PM, Erick Erickson > wrote: > > > Most likely reason is that the Solr node in question, > > was not reachable thus it was removed from > > live_nodes. Perhaps due to temporary network > > glitch, long GC pause or the like. If you're rolling > > your logs over it's quite possible that any illuminating > > messages were lost. The default 4M size for each > > log is quite lo at INFO level... > > > > It does seem possible for a Solr node to periodically > > check its status and re-insert itself into live_nodes, > > go through recovery and all that. So far most of that > > registration logic is baked into startup code. What > > do others think? Worth a JIRA? > > > > Erick > > > > On Tue, Dec 6, 2016 at 3:53 AM, Manohar Sripada > > wrote: > > > We have a 16 node cluster of Solr (5.2.1) and 5 node Zookeeper (3.4.6). > > > > > > All the Solr nodes were registered to Zookeeper (ls /live_nodes) when > > setup > > > was done 3 months back. Suddenly, few days back our search started > > failing > > > because one of the solr node(consider s16) was not seen in Zookeeper, > > i.e., > > > when we checked for *"ls /live_nodes"*, *s16 *solr node was not found. > > > However, the corresponding Solr process was up and running. > > > > > > To my surprise, I couldn't find any errors or warnings in solr or > > zookeeper > > > logs related to this. I have few questions - > > > > > > 1. Is there any reason why this registration to ZK was lost? I know > logs > > > should provide some information, but, it didn't. Did anyone encountered > > > similar issue, if so, what can be the root cause? > > > 2. Shouldn't Solr be clever enough to detect that the registration to > ZK > > > was lost (for some reason) and should try to re-register again? > > > > > > PS: The issue is resolved by restarting the Solr node. However, I am > > > curious to know why it happened in the first place. > > > > > > Thanks > > > -- - Mark about.me/markrmiller
Re: Difference between currency fieldType and float fieldType
Thanks for all the replies. Probably will have to go for long or currency fieldType. Int is still 32-bit, and there will be error in indexing if the amount is larger than 2,147,483,647. Since we are storing it as cents, it will hit the limit with just $21.4 million. Regards, Edwin On 7 December 2016 at 22:16, Esther-Melaine Quansah < esther.quan...@lucidworks.com> wrote: > Cool, that makes sense! > > Esther Quansah > > On Dec 7, 2016, at 9:13 AM, Dorian Hoxha wrote: > > > > Yeah, you always *100 when you store,query,facet, and you always /100 > when > > displaying. > > > > On Wed, Dec 7, 2016 at 3:07 PM, wrote: > > > >> I think Edwin might be concerned that in storing it as a long type, > there > >> will be no distinguishing between, in example, $1234.56 and $123456. > >> But correct me if I'm wrong - the latter would be stored as 12345600. > >> > >> When sending in a search for all values less than $100,000 on a long > >> field, will there be a need to send in that value in cents? (That is, > >> q=*:*&fq=long_field[* TO 1000] ) > >> > >> Thanks, > >> > >> Esther Quansah > >> > >>> Le 7 déc. 2016 à 07:26, Dorian Hoxha a écrit > : > >>> > >>> Come on dude, just use the int/long. > >>> Source: double is still a float. > >>> > >>> On Wed, Dec 7, 2016 at 1:17 PM, Zheng Lin Edwin Yeo < > >> edwinye...@gmail.com> > >>> wrote: > >>> > Thanks for the reply. > > How about using the double fieldType? > I tried that it works, as it is 64-bit, as compared to 32-bit for > float. > But will it hit the same issue again if the amount exceeds 64-bit? > > Regards, > Edwin > > > > On 7 December 2016 at 15:28, Dorian Hoxha > >> wrote: > > > > Yeah, you'll have to do the conversion yourself (or something > internal, > > like the currencyField). > > > > Think about it as datetimes. You store everything in utc (cents), but > > display to each user in it's own timezone (different currency, or > just > from > > cents to full dollars). > > > > On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo < > edwinye...@gmail.com> > > wrote: > > > >> But if I index $1234.56 as "123456", won't it affect the search or > facet > > if > >> I do a query directly to Solr? > >> > >> Say if I search for index with amount that is lesser that $2000, it > will > >> not match, unless when we do the search, we have to pass "20" to > > Solr? > >> > >> Regards, > >> Edwin > >> > >> > >> On 7 December 2016 at 07:44, Chris Hostetter < > >> hossman_luc...@fucit.org > > > >> wrote: > >> > >>> : Thanks for your reply. > >>> : > >>> : That means the best fieldType to use for money is currencyField, > and > >> not > >>> : any other fieldType? > >>> > >>> The primary use case for CurrencyField is when you want to do > dynamic > >>> currency fluctuations between multiple currency types at query time > -- > >> but > >>> to do that you either need to use the FileExchangeRateProvider and > have > >>> your owne backend system to update the exchange rates, or you have > to > >> have > >>> an openexchangerates.org account, or implement some other provider > > (with > >>> custom solr java code) > >>> > >>> > >>> If you only care about a single type of currency -- for example, if > all > >>> you care about is is US Dollars -- then just use either > >>> TrieIntField or TrieLongField and represent in the smallest > possible > >>> increment you need to measure -- for US Dollars this would be > cents. > > ie: > >>> $1234.56 would be put in your index as "123456" > >>> > >>> > >>> > >>> -Hoss > >>> http://www.lucidworks.com/ > >>> > >> > > > > >> > >
Re: Partial Field Update "removeregex" Command
if you want to remove all the data in the then use "null" in set
curl . . . -d '[{"id":"docId","someField":{"set",null}}]'
-Karthik
On Wed, Dec 7, 2016 at 1:31 PM, Richard Bergmann
wrote:
> Hello,
>
> I am new to this and have found no examples or guidance on how to use
> "removeregex" to remove (in my case) all entries in a multi-valued field.
>
> The following curl commands work just fine:
>
> curl . . . -d '[{"id":"docId","someField":{"add",["val1","val2"]}}]'
>
> and
>
> curl . . . -d '[{"id":"docId","someField":{"remove",["val1","val2"]}}]'
>
>
> None of the following have any effect, however:
>
> curl . . . -d '[{"id":"docId","someField":{"removeregex","val1"}}]'
>
> curl . . . -d '[{"id":"docId","someField":{"removeregex",".*"}}]'
>
>
> I appreciate your help and hope your answer makes it out on the cloud
> somewhere so others can find the solution.
>
> Regards,
>
> Rich Bergmann
>
Re: Solr Issue
It's possibly you have autosuggest configured and it's rebuilding on startup.
See "buildOnStartup" here:
https://cwiki.apache.org/confluence/display/solr/Suggester
Depending on the suggester, this will re-read _all_ documents
from the index to build the internal autosuggest structures which
can take many minutes. That would also explain Shawn's observation
that there is quite a gap in the timestamps.
Although I am puzzled by a couple of things:
1> There should be a message in your log
explicitly referencing building autosuggest. I don't see it.
2> this message:
o.a.s.c.CorePropertiesLocator Found 0 core
definitions
seems to indicate that there are no replicas on the server.
Best,
Erick
On Wed, Dec 7, 2016 at 9:01 AM, Shawn Heisey wrote:
> On 12/7/2016 3:24 AM, Monti Chandra wrote:
>> I am working on solr version to 6.2.1. It was working so nice for the first
>> 20 days and now the server is restarting very slow(15-20 min).
>> Please get the hardware specs of my system below:
>> Linux version 3.10.0-327.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc
>> version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )
>> kernel-3.10.0-327.el7.x86_64
>
> These are not hardware specs. They are software specs, and really don't
> contain anything useful. From this, we can tell that you are running
> CentOS 7 64-bit with a 3.10 kernel, and that's pretty much it.
>
>> It is working fine when i am taking solr directory to another server of
>> same configuartion.
>>
>> As I am using 6.2.1 basically, So i have downloaded the fresh
>> solr-6.2.1(without any collection) and try to start the same but the server
>> is not able to start effectively. please get the log below:
>
>> 596 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin used.
>> 127902 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
>> definitions underneath /root/temp/solr-6.2.1/server/solr
>> 127906 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
>> definitions
>> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
>> user.dir=/root/temp/solr-6.2.1/server
>> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
>> SolrDispatchFilter.init() done
>> 127918 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
>> o.e.j.w.WebAppContext@5383967b
>> {/solr,file:///root/temp/solr-6.2.1/server/solr-webapp/webapp/,AVAILABLE}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
>> 127926 INFO (main) [ ] o.e.j.s.ServerConnector Started
>> ServerConnector@1573f9fc{HTTP/1.1,[http/1.1]}{0.0.0.0:}
>> 127926 INFO (main) [ ] o.e.j.s.Server Started @128185ms
>>
>>
>> Is there any H/w, OS or kernel level threat caused by running solr? Please
>> help me I am wondering for a very long time.
>
> This log shows no errors. It says that Jetty is listening on port
> . It does look like it took a couple of minutes for Solr to finish
> starting, but other than that, I cannot see any problems here.
>
> Troubleshooting performance issues like this requires careful
> observation, and may be very difficult to do via a mailing list. We
> have pretty much zero information to go on, and the logs you have sent
> do not even contain any relevant warnings.
>
> There is only one odd thing. The log jumps from 596 milliseconds to
> 127902 milliseconds -- over two minutes with absolutely no information
> logged, after which it completes startup. When I start a
> freshly-downloaded Solr 6.2.1 in foreground mode, the time difference
> between these two log entries on my system is only 32 milliseconds, and
> then Solr is fully started less than a second later.
>
> 4271 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin used.
> 4303 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
> definitions underneath C:\Users\sheisey\Downloads\solr-6.2.1\server\solr
> 4552 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
> definitions
> 4552 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> user.dir=C:\Users\sheisey\Downloads\solr-6.2.1\server
> 4552 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> SolrDispatchFilter.init() done
> 4553 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
> o.e.j.w.WebAppContext@a67c67e{/solr,file:///C:/Users/sheisey/Downloads/solr-6.2.1/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\sheisey\Downloads\solr-6.2.1\server/solr-webapp/webapp}
> 4559 INFO (main) [ ] o.e.j.s.ServerConnector Started
> ServerConnector@4c12331b{HTTP/1.1,[http/1.1]}{0.0.0.0:8983}
> 4560 INFO (main) [ ] o.e.j.s.Server Started @5548ms
>
> Do you have any more information you can share? Something I'd like to
> see is a screenshot of "top" running in your terminal, after starting
> the fresh Solr with no collections. Before getting the screenshot,
> press shift-M to sort the list by memory usage.
>
> Thanks,
> Shawn
>
Partial Field Update "removeregex" Command
Hello,
I am new to this and have found no examples or guidance on how to use
"removeregex" to remove (in my case) all entries in a multi-valued field.
The following curl commands work just fine:
curl . . . -d '[{"id":"docId","someField":{"add",["val1","val2"]}}]'
and
curl . . . -d '[{"id":"docId","someField":{"remove",["val1","val2"]}}]'
None of the following have any effect, however:
curl . . . -d '[{"id":"docId","someField":{"removeregex","val1"}}]'
curl . . . -d '[{"id":"docId","someField":{"removeregex",".*"}}]'
I appreciate your help and hope your answer makes it out on the cloud somewhere
so others can find the solution.
Regards,
Rich Bergmann
Re: Configuration folder for the collection generated with instead of just
Nicole - Since this is probably off-topic for the solr-user list, let’s take this offline and over to your Lucidworks support. But while we’re here, here’s an example of using the Fusion API to create a collection and then the Solr API to configure the schema. In this example, it’s not using the zkcli to upconfig, though I’ve done that technique as well with no problems. Something is fishy, obviously, with the discrepancy of your config set and your collection name, but I’m not sure where that is coming from. Feel free to reply to me offline at "erik hatcher @ lucidworks.com" with the exact commands that you’ve issued and I’ll get a support ticket opened for you. Erik > On Dec 7, 2016, at 6:06 AM, Nicole Bilić wrote: > > Good suggestion, but unfortunately it does not address this issue as we are > not using the time-based partitioning in this project. > > It would be useful to know in which case is the configuration created with > in Solr, what scenario does lead to that so we can > investigate further. Any other suggestions? > > Thanks > > On Wed, Dec 7, 2016 at 1:53 PM, Erik Hatcher wrote: > >> Looks best to file that as a Lucidworks support ticket. >> >> But are you using the time-based sharding feature of Fusion? If that's >> the case that might explain it as that creates collections for each time >> partition. >> >>Erik >> >>> On Dec 7, 2016, at 00:31, Nicole Bilić wrote: >>> >>> Hi all, >>> >>> >>> We are using Lucidworks Fusion on top of Solr and recently we’ve >>> encountered an unexpected behavior. We’ve created bash scripts which we >> use >>> to create collections in Solr using the Fusion API and upload the >>> collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir >> $path >>> -confname $collection -z $HOST:$ZKPORT). >>> >>> We had issues that the index fields of our custom configurations were not >>> available (ie. our custom field types and fields we’ve defined in >>> managed-schema). So we checked in Solr admin and found out that the >>> configuration folder for the collection was generated with >>> instead of just (eg. >>> https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/ >> view?usp=sharing). >>> >>> >>> Our collection configurations are under the one with the id in the end. >> So >>> the configuration set that was uploaded by our scripts was never used and >>> therefore the index fields were not existing. Also, we did not manage to >>> discover a pattern (or cause) for when does this happen (because >> sometimes >>> the issue does not occur and sometimes it does and to us it seems pretty >>> nondeterministic). >>> >>> Furthermore, in the screenshot above, it’s possible to see the same thing >>> happened with system_metrics collection configs, which we do not create >> or >>> modify with our scripts. Therefore, the scripts should not be the cause >> of >>> this behavior. >>> >>> What we are trying to determine is if this issue is coming from Fusion, >>> Solr or Zookeeper. Does someone know in which case the collection >>> configuration folder is generated with the id in the end and how to avoid >>> it? Thank you! >>> >>> >>> Nicole >>
Re: Solr Issue
On 12/7/2016 3:24 AM, Monti Chandra wrote:
> I am working on solr version to 6.2.1. It was working so nice for the first
> 20 days and now the server is restarting very slow(15-20 min).
> Please get the hardware specs of my system below:
> Linux version 3.10.0-327.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc
> version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )
> kernel-3.10.0-327.el7.x86_64
These are not hardware specs. They are software specs, and really don't
contain anything useful. From this, we can tell that you are running
CentOS 7 64-bit with a 3.10 kernel, and that's pretty much it.
> It is working fine when i am taking solr directory to another server of
> same configuartion.
>
> As I am using 6.2.1 basically, So i have downloaded the fresh
> solr-6.2.1(without any collection) and try to start the same but the server
> is not able to start effectively. please get the log below:
> 596 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin used.
> 127902 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
> definitions underneath /root/temp/solr-6.2.1/server/solr
> 127906 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
> definitions
> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> user.dir=/root/temp/solr-6.2.1/server
> 127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> SolrDispatchFilter.init() done
> 127918 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
> o.e.j.w.WebAppContext@5383967b
> {/solr,file:///root/temp/solr-6.2.1/server/solr-webapp/webapp/,AVAILABLE}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
> 127926 INFO (main) [ ] o.e.j.s.ServerConnector Started
> ServerConnector@1573f9fc{HTTP/1.1,[http/1.1]}{0.0.0.0:}
> 127926 INFO (main) [ ] o.e.j.s.Server Started @128185ms
>
>
> Is there any H/w, OS or kernel level threat caused by running solr? Please
> help me I am wondering for a very long time.
This log shows no errors. It says that Jetty is listening on port
. It does look like it took a couple of minutes for Solr to finish
starting, but other than that, I cannot see any problems here.
Troubleshooting performance issues like this requires careful
observation, and may be very difficult to do via a mailing list. We
have pretty much zero information to go on, and the logs you have sent
do not even contain any relevant warnings.
There is only one odd thing. The log jumps from 596 milliseconds to
127902 milliseconds -- over two minutes with absolutely no information
logged, after which it completes startup. When I start a
freshly-downloaded Solr 6.2.1 in foreground mode, the time difference
between these two log entries on my system is only 32 milliseconds, and
then Solr is fully started less than a second later.
4271 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin used.
4303 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
definitions underneath C:\Users\sheisey\Downloads\solr-6.2.1\server\solr
4552 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
definitions
4552 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
user.dir=C:\Users\sheisey\Downloads\solr-6.2.1\server
4552 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
SolrDispatchFilter.init() done
4553 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
o.e.j.w.WebAppContext@a67c67e{/solr,file:///C:/Users/sheisey/Downloads/solr-6.2.1/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\sheisey\Downloads\solr-6.2.1\server/solr-webapp/webapp}
4559 INFO (main) [ ] o.e.j.s.ServerConnector Started
ServerConnector@4c12331b{HTTP/1.1,[http/1.1]}{0.0.0.0:8983}
4560 INFO (main) [ ] o.e.j.s.Server Started @5548ms
Do you have any more information you can share? Something I'd like to
see is a screenshot of "top" running in your terminal, after starting
the fresh Solr with no collections. Before getting the screenshot,
press shift-M to sort the list by memory usage.
Thanks,
Shawn
Cannot use Properties in a CDCR Request Handler Definition
I have been testing and setting up CDCR replication between Solrcloud
instances.
We are currently using Solr 6.2
We have a lot of collections and a number of environments for testing and
deployment. It seemed that using properties in the cdcrRequestHandler would
help a lot. Since we have a naming convention and collection names should
be the same between clouds I tried using property names for the source and
target collection, and for the target Zookeeper.
We also use the Config-API to create and change the request handler.
{"responseHeader": {"status": 0,"QTime": 2},"overlay": {"znodeVersion": 17,"
requestHandler": {"/cdcr": {"name": "/cdcr","class": "
solr.CdcrRequestHandler","replica": {"zkHost": "${targetZk}","source":
"${solr.core.collection}","target": "${solr.core.collection}"},"replicator
": {"threadPoolSize": 2,"schedule": 500,"batchSize": 128},"
updateLogSynchronizer": {"schedule": 6}}},"userProps": {"targetZk": "
stldeepx06.sial.com:2181/solr"}}}
I cannot get this to work unless I remove all the property definitions and
use the real names:
This works:
{"responseHeader": {"status": 0,"QTime": 2},"overlay": {"znodeVersion": 17,"
requestHandler": {"/cdcr": {"name": "/cdcr","class": "
solr.CdcrRequestHandler","replica": {"zkHost": "
stldeepx06.sial.com:2181/solr","source": "sial-catalog-product","target": "
sial-catalog-product"},"replicator": {"threadPoolSize": 2,"schedule": 500,"
batchSize": 128},"updateLogSynchronizer": {"schedule": 6}
replication fails when any of the parameters are properties. Even though
the documentation has an example that uses properties.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62687462#CrossDataCenterReplication(CDCR)-InitialStartup
This seems like a defect, at least a problem with the docs, but I would
expect properties to work, or is it just that it doesn't work with the
Config-API?
Thanks,
Web
--
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.merckgroup.com/disclaimer to access the German, French,
Spanish and Portuguese versions of this disclaimer.
Re: solr audit logging
Thanks very much every one. They will probably pursue custom code to see if they can get this data and log it. J -- Thanks, Jeff Courtade M: 240.507.6116 On Tue, Dec 6, 2016 at 7:07 PM, John Bickerstaff wrote: > You know - if I had to build this, I would consider slurping up the > relevant log entries (if they exist) and feeding them to Kafka - then your > people who want to analyze what happened can get those entries again and > again (Think of Kafka kind of like a persistent messaging store that can > store log entries or anything you want...) > > Of course, how much work you'd have to put into that depends on the > technical skill of whoever is going to consume this stuff... > > Also, a plain old relational database can easily hold these things as well > -and the code to parse the log messages into some simple tables wouldn't be > that difficult... There are probably existing examples / projects... > > Naturally - if the standard log entries do NOT get you what you need, then > it gets to be more of an effort, although adding an extension to Solr isn't > too hard once you understand the process... > > Ping back and let us know what you find in the logs and if you want more > "advice" -- which you should always take with a grain of salt... > > On Tue, Dec 6, 2016 at 3:56 PM, John Bickerstaff > > wrote: > > > If you can identify currently-logged messages that give you what you need > > (even if you have to modify or process them afterwards) you can easily > make > > a custom log4j config that grabs ONLY what you want and dumps it into a > > separate file... > > > > I'm pretty sure I've seen all the request coming through in my SOLR log > > files... > > > > In case that helps... > > > > On Tue, Dec 6, 2016 at 2:08 PM, Alexandre Rafalovitch < > arafa...@gmail.com> > > wrote: > > > >> There is also Jetty level access log which shows the requests, though > >> it may not show the HTTP PUT bodies. > >> > >> Finally, various online monitoring services probably have agents that > >> integrate with Solr to show what's happening. Usually costs money > >> though. > >> > >> Regards, > >> Alex. > >> > >> http://www.solr-start.com/ - Resources for Solr users, new and > >> experienced > >> > >> > >> On 6 December 2016 at 14:34, Jeff Courtade > >> wrote: > >> > Thanks very much the trace idea is a brilliant way to dig into it. Did > >> not > >> > occur to me. > >> > > >> > I had another coworker suggest the custom > >> > > >> > http://lucene.apache.org/solr/6_3_0/solr-core/org/apache/sol > >> r/update/processor/LogUpdateProcessorFactory.html > >> > > >> > > >> > this is beyond my litmited abilites. > >> > > >> > > >> > I will see what we can dig up out of the logs... > >> > > >> > > >> > the original request was this... > >> > > >> > > >> > "Is there any configuration, plugin, or application that will create > an > >> > audit trail for Solr requests? We have teams that would like to be > able > >> to > >> > pull back changes/requests to documents in solr given a time period. > The > >> > information they would like to retrieve is the request to solr, where > it > >> > came from, and what the request did." > >> > > >> > > >> > I am starting to think there is not a simple solution to this. I was > >> hoping > >> > there was an UpdateAudit class or something I could flip a switch on > or > >> > some such... > >> > > >> > > >> > > >> > On Tue, Dec 6, 2016 at 2:20 PM, Alexandre Rafalovitch < > >> arafa...@gmail.com> > >> > wrote: > >> > > >> >> You could turn the trace mode for everything in the Admin UI (under > >> >> logs/levels) and see if any of the existing information is sufficient > >> >> for your needs. If yes, then you change log level in the > configuration > >> >> just for that class/element. > >> >> > >> >> Alternatively, you could do a custom UpdateRequestProcessor in the > >> >> request handler(s) that deal with update. Or perhaps > >> >> LogUpdateProcessor (that's in every standard chain) is sufficient: > >> >> http://www.solr-start.com/javadoc/solr-lucene/org/ > >> >> apache/solr/update/processor/LogUpdateProcessorFactory.html > >> >> > >> >> But it is also possible that the audit.log is something that has a > >> >> specific format that other tools use. So, you could start from asking > >> >> how that file would be used and then working backwards into Solr. > >> >> Which would most likely be a custom URP, as I mentioned earlier. > >> >> > >> >> Regards, > >> >>Alex. > >> >> P.s. Remember that there are full document updates and partial > >> >> updates. What you want to log about that is your business level > >> >> decision. > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, > >> > > >> > Jeff Courtade > >> > M: 240.507.6116 > >> > > > > >
Re: Difference between currency fieldType and float fieldType
Cool, that makes sense! Esther Quansah > On Dec 7, 2016, at 9:13 AM, Dorian Hoxha wrote: > > Yeah, you always *100 when you store,query,facet, and you always /100 when > displaying. > > On Wed, Dec 7, 2016 at 3:07 PM, wrote: > >> I think Edwin might be concerned that in storing it as a long type, there >> will be no distinguishing between, in example, $1234.56 and $123456. >> But correct me if I'm wrong - the latter would be stored as 12345600. >> >> When sending in a search for all values less than $100,000 on a long >> field, will there be a need to send in that value in cents? (That is, >> q=*:*&fq=long_field[* TO 1000] ) >> >> Thanks, >> >> Esther Quansah >> >>> Le 7 déc. 2016 à 07:26, Dorian Hoxha a écrit : >>> >>> Come on dude, just use the int/long. >>> Source: double is still a float. >>> >>> On Wed, Dec 7, 2016 at 1:17 PM, Zheng Lin Edwin Yeo < >> edwinye...@gmail.com> >>> wrote: >>> Thanks for the reply. How about using the double fieldType? I tried that it works, as it is 64-bit, as compared to 32-bit for float. But will it hit the same issue again if the amount exceeds 64-bit? Regards, Edwin > On 7 December 2016 at 15:28, Dorian Hoxha >> wrote: > > Yeah, you'll have to do the conversion yourself (or something internal, > like the currencyField). > > Think about it as datetimes. You store everything in utc (cents), but > display to each user in it's own timezone (different currency, or just from > cents to full dollars). > > On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo < edwinye...@gmail.com> > wrote: > >> But if I index $1234.56 as "123456", won't it affect the search or facet > if >> I do a query directly to Solr? >> >> Say if I search for index with amount that is lesser that $2000, it will >> not match, unless when we do the search, we have to pass "20" to > Solr? >> >> Regards, >> Edwin >> >> >> On 7 December 2016 at 07:44, Chris Hostetter < >> hossman_luc...@fucit.org > >> wrote: >> >>> : Thanks for your reply. >>> : >>> : That means the best fieldType to use for money is currencyField, and >> not >>> : any other fieldType? >>> >>> The primary use case for CurrencyField is when you want to do dynamic >>> currency fluctuations between multiple currency types at query time -- >> but >>> to do that you either need to use the FileExchangeRateProvider and have >>> your owne backend system to update the exchange rates, or you have to >> have >>> an openexchangerates.org account, or implement some other provider > (with >>> custom solr java code) >>> >>> >>> If you only care about a single type of currency -- for example, if all >>> you care about is is US Dollars -- then just use either >>> TrieIntField or TrieLongField and represent in the smallest possible >>> increment you need to measure -- for US Dollars this would be cents. > ie: >>> $1234.56 would be put in your index as "123456" >>> >>> >>> >>> -Hoss >>> http://www.lucidworks.com/ >>> >> > >>
Re: Difference between currency fieldType and float fieldType
Yeah, you always *100 when you store,query,facet, and you always /100 when displaying. On Wed, Dec 7, 2016 at 3:07 PM, wrote: > I think Edwin might be concerned that in storing it as a long type, there > will be no distinguishing between, in example, $1234.56 and $123456. > But correct me if I'm wrong - the latter would be stored as 12345600. > > When sending in a search for all values less than $100,000 on a long > field, will there be a need to send in that value in cents? (That is, > q=*:*&fq=long_field[* TO 1000] ) > > Thanks, > > Esther Quansah > > > Le 7 déc. 2016 à 07:26, Dorian Hoxha a écrit : > > > > Come on dude, just use the int/long. > > Source: double is still a float. > > > > On Wed, Dec 7, 2016 at 1:17 PM, Zheng Lin Edwin Yeo < > edwinye...@gmail.com> > > wrote: > > > >> Thanks for the reply. > >> > >> How about using the double fieldType? > >> I tried that it works, as it is 64-bit, as compared to 32-bit for float. > >> But will it hit the same issue again if the amount exceeds 64-bit? > >> > >> Regards, > >> Edwin > >> > >> > >>> On 7 December 2016 at 15:28, Dorian Hoxha > wrote: > >>> > >>> Yeah, you'll have to do the conversion yourself (or something internal, > >>> like the currencyField). > >>> > >>> Think about it as datetimes. You store everything in utc (cents), but > >>> display to each user in it's own timezone (different currency, or just > >> from > >>> cents to full dollars). > >>> > >>> On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo < > >> edwinye...@gmail.com> > >>> wrote: > >>> > But if I index $1234.56 as "123456", won't it affect the search or > >> facet > >>> if > I do a query directly to Solr? > > Say if I search for index with amount that is lesser that $2000, it > >> will > not match, unless when we do the search, we have to pass "20" to > >>> Solr? > > Regards, > Edwin > > > On 7 December 2016 at 07:44, Chris Hostetter < > hossman_luc...@fucit.org > >>> > wrote: > > > : Thanks for your reply. > > : > > : That means the best fieldType to use for money is currencyField, > >> and > not > > : any other fieldType? > > > > The primary use case for CurrencyField is when you want to do dynamic > > currency fluctuations between multiple currency types at query time > >> -- > but > > to do that you either need to use the FileExchangeRateProvider and > >> have > > your owne backend system to update the exchange rates, or you have to > have > > an openexchangerates.org account, or implement some other provider > >>> (with > > custom solr java code) > > > > > > If you only care about a single type of currency -- for example, if > >> all > > you care about is is US Dollars -- then just use either > > TrieIntField or TrieLongField and represent in the smallest possible > > increment you need to measure -- for US Dollars this would be cents. > >>> ie: > > $1234.56 would be put in your index as "123456" > > > > > > > > -Hoss > > http://www.lucidworks.com/ > > > > >>> > >> >
Re: Difference between currency fieldType and float fieldType
I think Edwin might be concerned that in storing it as a long type, there will be no distinguishing between, in example, $1234.56 and $123456. But correct me if I'm wrong - the latter would be stored as 12345600. When sending in a search for all values less than $100,000 on a long field, will there be a need to send in that value in cents? (That is, q=*:*&fq=long_field[* TO 1000] ) Thanks, Esther Quansah > Le 7 déc. 2016 à 07:26, Dorian Hoxha a écrit : > > Come on dude, just use the int/long. > Source: double is still a float. > > On Wed, Dec 7, 2016 at 1:17 PM, Zheng Lin Edwin Yeo > wrote: > >> Thanks for the reply. >> >> How about using the double fieldType? >> I tried that it works, as it is 64-bit, as compared to 32-bit for float. >> But will it hit the same issue again if the amount exceeds 64-bit? >> >> Regards, >> Edwin >> >> >>> On 7 December 2016 at 15:28, Dorian Hoxha wrote: >>> >>> Yeah, you'll have to do the conversion yourself (or something internal, >>> like the currencyField). >>> >>> Think about it as datetimes. You store everything in utc (cents), but >>> display to each user in it's own timezone (different currency, or just >> from >>> cents to full dollars). >>> >>> On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo < >> edwinye...@gmail.com> >>> wrote: >>> But if I index $1234.56 as "123456", won't it affect the search or >> facet >>> if I do a query directly to Solr? Say if I search for index with amount that is lesser that $2000, it >> will not match, unless when we do the search, we have to pass "20" to >>> Solr? Regards, Edwin On 7 December 2016 at 07:44, Chris Hostetter >> wrote: > : Thanks for your reply. > : > : That means the best fieldType to use for money is currencyField, >> and not > : any other fieldType? > > The primary use case for CurrencyField is when you want to do dynamic > currency fluctuations between multiple currency types at query time >> -- but > to do that you either need to use the FileExchangeRateProvider and >> have > your owne backend system to update the exchange rates, or you have to have > an openexchangerates.org account, or implement some other provider >>> (with > custom solr java code) > > > If you only care about a single type of currency -- for example, if >> all > you care about is is US Dollars -- then just use either > TrieIntField or TrieLongField and represent in the smallest possible > increment you need to measure -- for US Dollars this would be cents. >>> ie: > $1234.56 would be put in your index as "123456" > > > > -Hoss > http://www.lucidworks.com/ > >>> >>
Re: Configuration folder for the collection generated with instead of just
Good suggestion, but unfortunately it does not address this issue as we are not using the time-based partitioning in this project. It would be useful to know in which case is the configuration created with in Solr, what scenario does lead to that so we can investigate further. Any other suggestions? Thanks On Wed, Dec 7, 2016 at 1:53 PM, Erik Hatcher wrote: > Looks best to file that as a Lucidworks support ticket. > > But are you using the time-based sharding feature of Fusion? If that's > the case that might explain it as that creates collections for each time > partition. > > Erik > > > On Dec 7, 2016, at 00:31, Nicole Bilić wrote: > > > > Hi all, > > > > > > We are using Lucidworks Fusion on top of Solr and recently we’ve > > encountered an unexpected behavior. We’ve created bash scripts which we > use > > to create collections in Solr using the Fusion API and upload the > > collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir > $path > > -confname $collection -z $HOST:$ZKPORT). > > > > We had issues that the index fields of our custom configurations were not > > available (ie. our custom field types and fields we’ve defined in > > managed-schema). So we checked in Solr admin and found out that the > > configuration folder for the collection was generated with > > instead of just (eg. > > https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/ > view?usp=sharing). > > > > > > Our collection configurations are under the one with the id in the end. > So > > the configuration set that was uploaded by our scripts was never used and > > therefore the index fields were not existing. Also, we did not manage to > > discover a pattern (or cause) for when does this happen (because > sometimes > > the issue does not occur and sometimes it does and to us it seems pretty > > nondeterministic). > > > > Furthermore, in the screenshot above, it’s possible to see the same thing > > happened with system_metrics collection configs, which we do not create > or > > modify with our scripts. Therefore, the scripts should not be the cause > of > > this behavior. > > > > What we are trying to determine is if this issue is coming from Fusion, > > Solr or Zookeeper. Does someone know in which case the collection > > configuration folder is generated with the id in the end and how to avoid > > it? Thank you! > > > > > > Nicole >
Re: Configuration folder for the collection generated with instead of just
Looks best to file that as a Lucidworks support ticket. But are you using the time-based sharding feature of Fusion? If that's the case that might explain it as that creates collections for each time partition. Erik > On Dec 7, 2016, at 00:31, Nicole Bilić wrote: > > Hi all, > > > We are using Lucidworks Fusion on top of Solr and recently we’ve > encountered an unexpected behavior. We’ve created bash scripts which we use > to create collections in Solr using the Fusion API and upload the > collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir $path > -confname $collection -z $HOST:$ZKPORT). > > We had issues that the index fields of our custom configurations were not > available (ie. our custom field types and fields we’ve defined in > managed-schema). So we checked in Solr admin and found out that the > configuration folder for the collection was generated with > instead of just (eg. > https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/view?usp=sharing). > > > Our collection configurations are under the one with the id in the end. So > the configuration set that was uploaded by our scripts was never used and > therefore the index fields were not existing. Also, we did not manage to > discover a pattern (or cause) for when does this happen (because sometimes > the issue does not occur and sometimes it does and to us it seems pretty > nondeterministic). > > Furthermore, in the screenshot above, it’s possible to see the same thing > happened with system_metrics collection configs, which we do not create or > modify with our scripts. Therefore, the scripts should not be the cause of > this behavior. > > What we are trying to determine is if this issue is coming from Fusion, > Solr or Zookeeper. Does someone know in which case the collection > configuration folder is generated with the id in the end and how to avoid > it? Thank you! > > > Nicole
Re: Difference between currency fieldType and float fieldType
Come on dude, just use the int/long. Source: double is still a float. On Wed, Dec 7, 2016 at 1:17 PM, Zheng Lin Edwin Yeo wrote: > Thanks for the reply. > > How about using the double fieldType? > I tried that it works, as it is 64-bit, as compared to 32-bit for float. > But will it hit the same issue again if the amount exceeds 64-bit? > > Regards, > Edwin > > > On 7 December 2016 at 15:28, Dorian Hoxha wrote: > > > Yeah, you'll have to do the conversion yourself (or something internal, > > like the currencyField). > > > > Think about it as datetimes. You store everything in utc (cents), but > > display to each user in it's own timezone (different currency, or just > from > > cents to full dollars). > > > > On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo < > edwinye...@gmail.com> > > wrote: > > > > > But if I index $1234.56 as "123456", won't it affect the search or > facet > > if > > > I do a query directly to Solr? > > > > > > Say if I search for index with amount that is lesser that $2000, it > will > > > not match, unless when we do the search, we have to pass "20" to > > Solr? > > > > > > Regards, > > > Edwin > > > > > > > > > On 7 December 2016 at 07:44, Chris Hostetter > > > > wrote: > > > > > > > : Thanks for your reply. > > > > : > > > > : That means the best fieldType to use for money is currencyField, > and > > > not > > > > : any other fieldType? > > > > > > > > The primary use case for CurrencyField is when you want to do dynamic > > > > currency fluctuations between multiple currency types at query time > -- > > > but > > > > to do that you either need to use the FileExchangeRateProvider and > have > > > > your owne backend system to update the exchange rates, or you have to > > > have > > > > an openexchangerates.org account, or implement some other provider > > (with > > > > custom solr java code) > > > > > > > > > > > > If you only care about a single type of currency -- for example, if > all > > > > you care about is is US Dollars -- then just use either > > > > TrieIntField or TrieLongField and represent in the smallest possible > > > > increment you need to measure -- for US Dollars this would be cents. > > ie: > > > > $1234.56 would be put in your index as "123456" > > > > > > > > > > > > > > > > -Hoss > > > > http://www.lucidworks.com/ > > > > > > > > > >
Re: Difference between currency fieldType and float fieldType
Thanks for the reply. How about using the double fieldType? I tried that it works, as it is 64-bit, as compared to 32-bit for float. But will it hit the same issue again if the amount exceeds 64-bit? Regards, Edwin On 7 December 2016 at 15:28, Dorian Hoxha wrote: > Yeah, you'll have to do the conversion yourself (or something internal, > like the currencyField). > > Think about it as datetimes. You store everything in utc (cents), but > display to each user in it's own timezone (different currency, or just from > cents to full dollars). > > On Wed, Dec 7, 2016 at 8:23 AM, Zheng Lin Edwin Yeo > wrote: > > > But if I index $1234.56 as "123456", won't it affect the search or facet > if > > I do a query directly to Solr? > > > > Say if I search for index with amount that is lesser that $2000, it will > > not match, unless when we do the search, we have to pass "20" to > Solr? > > > > Regards, > > Edwin > > > > > > On 7 December 2016 at 07:44, Chris Hostetter > > wrote: > > > > > : Thanks for your reply. > > > : > > > : That means the best fieldType to use for money is currencyField, and > > not > > > : any other fieldType? > > > > > > The primary use case for CurrencyField is when you want to do dynamic > > > currency fluctuations between multiple currency types at query time -- > > but > > > to do that you either need to use the FileExchangeRateProvider and have > > > your owne backend system to update the exchange rates, or you have to > > have > > > an openexchangerates.org account, or implement some other provider > (with > > > custom solr java code) > > > > > > > > > If you only care about a single type of currency -- for example, if all > > > you care about is is US Dollars -- then just use either > > > TrieIntField or TrieLongField and represent in the smallest possible > > > increment you need to measure -- for US Dollars this would be cents. > ie: > > > $1234.56 would be put in your index as "123456" > > > > > > > > > > > > -Hoss > > > http://www.lucidworks.com/ > > > > > >
Solr Issue
Hello team,
I am working on solr version to 6.2.1. It was working so nice for the first
20 days and now the server is restarting very slow(15-20 min).
Please get the hardware specs of my system below:
Linux version 3.10.0-327.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc
version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )
kernel-3.10.0-327.el7.x86_64
It is working fine when i am taking solr directory to another server of
same configuartion.
As I am using 6.2.1 basically, So i have downloaded the fresh
solr-6.2.1(without any collection) and try to start the same but the server
is not able to start effectively. please get the log below:
0INFO (main) [ ] o.e.j.u.log Logging initialized @257ms
131 INFO (main) [ ] o.e.j.s.Server jetty-9.3.8.v20160314
146 INFO (main) [ ] o.e.j.d.p.ScanningAppProvider Deployment monitor
[file:///root/temp/solr-6.2.1/server/contexts/] at interval 0
311 INFO (main) [ ] o.e.j.w.StandardDescriptorProcessor NO JSP Support
for /solr, did not find org.apache.jasper.servlet.JspServlet
320 WARN (main) [ ] o.e.j.s.SecurityHandler
ServletContext@o.e.j.w.WebAppContext@5383967b{/solr,file:///root/temp/solr-6.2.1/server/solr-webapp/webapp/,STARTING}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
has uncovered http methods for path: /
327 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
SolrDispatchFilter.init(): WebAppClassLoader=1465085305@57536d79
340 INFO (main) [ ] o.a.s.c.SolrResourceLoader JNDI not configured for
solr (NoInitialContextEx)
340 INFO (main) [ ] o.a.s.c.SolrResourceLoader using system property
solr.solr.home: /root/temp/solr-6.2.1/server/solr
340 INFO (main) [ ] o.a.s.c.SolrResourceLoader new SolrResourceLoader
for directory: '/root/temp/solr-6.2.1/server/solr'
340 INFO (main) [ ] o.a.s.c.SolrResourceLoader JNDI not configured for
solr (NoInitialContextEx)
340 INFO (main) [ ] o.a.s.c.SolrResourceLoader using system property
solr.solr.home: /root/temp/solr-6.2.1/server/solr
345 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading container
configuration from /root/temp/solr-6.2.1/server/solr/solr.xml
402 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Config-defined core
root directory: /root/temp/solr-6.2.1/server/solr
424 INFO (main) [ ] o.a.s.c.CoreContainer New CoreContainer 1663619914
425 INFO (main) [ ] o.a.s.c.CoreContainer Loading cores into
CoreContainer [instanceDir=/root/temp/solr-6.2.1/server/solr]
425 WARN (main) [ ] o.a.s.c.CoreContainer Couldn't add files from
/root/temp/solr-6.2.1/server/solr/lib to classpath:
/root/temp/solr-6.2.1/server/solr/lib
434 INFO (main) [ ] o.a.s.h.c.HttpShardHandlerFactory created with
socketTimeout : 60,connTimeout : 6,maxConnectionsPerHost :
20,maxConnections : 1,corePoolSize : 0,maximumPoolSize :
2147483647,maxThreadIdleTime : 5,sizeOfQueue : -1,fairnessPolicy :
false,useRetries : false,connectionsEvictorSleepDelay :
5000,maxConnectionIdleTime : 4,
592 INFO (main) [ ] o.a.s.u.UpdateShardHandler Creating
UpdateShardHandler HTTP client with params:
socketTimeout=60&connTimeout=6&retry=true
594 INFO (main) [ ] o.a.s.l.LogWatcher SLF4J impl is
org.slf4j.impl.Log4jLoggerFactory
594 INFO (main) [ ] o.a.s.l.LogWatcher Registering Log Listener [Log4j
(org.slf4j.impl.Log4jLoggerFactory)]
596 INFO (main) [ ] o.a.s.c.CoreContainer Security conf doesn't exist.
Skipping setup for authorization module.
596 INFO (main) [ ] o.a.s.c.CoreContainer No authentication plugin used.
127902 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Looking for core
definitions underneath /root/temp/solr-6.2.1/server/solr
127906 INFO (main) [ ] o.a.s.c.CorePropertiesLocator Found 0 core
definitions
127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
user.dir=/root/temp/solr-6.2.1/server
127909 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
SolrDispatchFilter.init() done
127918 INFO (main) [ ] o.e.j.s.h.ContextHandler Started
o.e.j.w.WebAppContext@5383967b
{/solr,file:///root/temp/solr-6.2.1/server/solr-webapp/webapp/,AVAILABLE}{/root/temp/solr-6.2.1/server/solr-webapp/webapp}
127926 INFO (main) [ ] o.e.j.s.ServerConnector Started
ServerConnector@1573f9fc{HTTP/1.1,[http/1.1]}{0.0.0.0:}
127926 INFO (main) [ ] o.e.j.s.Server Started @128185ms
Is there any H/w, OS or kernel level threat caused by running solr? Please
help me I am wondering for a very long time.
--
*Thanks & Regards*
MONTI CHANDRA
Configuration folder for the collection generated with instead of just
Hi all, We are using Lucidworks Fusion on top of Solr and recently we’ve encountered an unexpected behavior. We’ve created bash scripts which we use to create collections in Solr using the Fusion API and upload the collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir $path -confname $collection -z $HOST:$ZKPORT). We had issues that the index fields of our custom configurations were not available (ie. our custom field types and fields we’ve defined in managed-schema). So we checked in Solr admin and found out that the configuration folder for the collection was generated with instead of just (eg. https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/view?usp=sharing). Our collection configurations are under the one with the id in the end. So the configuration set that was uploaded by our scripts was never used and therefore the index fields were not existing. Also, we did not manage to discover a pattern (or cause) for when does this happen (because sometimes the issue does not occur and sometimes it does and to us it seems pretty nondeterministic). Furthermore, in the screenshot above, it’s possible to see the same thing happened with system_metrics collection configs, which we do not create or modify with our scripts. Therefore, the scripts should not be the cause of this behavior. What we are trying to determine is if this issue is coming from Fusion, Solr or Zookeeper. Does someone know in which case the collection configuration folder is generated with the id in the end and how to avoid it? Thank you! Nicole
Re: Memory leak in Solr
What do you mean by JVM level? Run Solr on different ports on the same machine? If you have a 32 core box would you run 2,3,4 JVMs? On Sun, Dec 4, 2016 at 8:46 PM, Jeff Wartes wrote: > > Here’s an earlier post where I mentioned some GC investigation tools: > https://mail-archives.apache.org/mod_mbox/lucene-solr-user/ > 201604.mbox/%3c8f8fa32d-ec0e-4352-86f7-4b2d8a906...@whitepages.com%3E > > In my experience, there are many aspects of the Solr/Lucene memory > allocation model that scale with things other than documents returned. > (such as cardinality, or simply index size) A single query on a large index > might consume dozens of megabytes of heap to complete. But that heap should > also be released quickly after the query finishes. > The key characteristic of a memory leak is that the software is allocating > memory that it cannot reclaim. If it’s a leak, you ought to be able to > reproduce it at any query rate - have you tried this? A run with, say, half > the rate, over twice the duration? > > I’m inclined to agree with others here, that although you’ve correctly > attributed the cause to GC, it’s probably less an indication of a leak, and > more an indication of simply allocating memory faster than it can be > reclaimed, combined with the long pauses that are increasingly unavoidable > as heap size goes up. > Note that in the case of a CMS allocation failure, the fallback full-GC is > *single threaded*, which means it’ll usually take considerably longer than > a normal GC - even for a comparable amount of garbage. > > In addition to GC tuning, you can address these by sharding more, both at > the core and jvm level. > > > On 12/4/16, 3:46 PM, "Shawn Heisey" wrote: > > On 12/3/2016 9:46 PM, S G wrote: > > The symptom we see is that the java clients querying Solr see > response > > times in 10s of seconds (not milliseconds). > > > Some numbers for the Solr Cloud: > > > > *Overall infrastructure:* > > - Only one collection > > - 16 VMs used > > - 8 shards (1 leader and 1 replica per shard - each core on separate > VM) > > > > *Overview from one core:* > > - Num Docs:193,623,388 > > - Max Doc:230,577,696 > > - Heap Memory Usage:231,217,880 > > - Deleted Docs:36,954,308 > > - Version:2,357,757 > > - Segment Count:37 > > The heap memory usage number isn't useful. It doesn't cover all the > memory used. > > > *Stats from QueryHandler/select* > > - requests:78,557 > > - errors:358 > > - timeouts:0 > > - totalTime:1,639,975.27 > > - avgRequestsPerSecond:2.62 > > - 5minRateReqsPerSecond:1.39 > > - 15minRateReqsPerSecond:1.64 > > - avgTimePerRequest:20.87 > > - medianRequestTime:0.70 > > - 75thPcRequestTime:1.11 > > - 95thPcRequestTime:191.76 > > These times are in *milliseconds*, not seconds .. and these are even > better numbers than you showed before. Where are you seeing 10 plus > second query times? Solr is not showing numbers like that. > > If your VM host has 16 VMs on it and each one has a total memory size > of > 92GB, then if that machine doesn't have 1.5 terabytes of memory, you're > oversubscribed, and this is going to lead to terrible performance... > but > the numbers you've shown here do not show terrible performance. > > > Plus, on every server, we are seeing lots of exceptions. > > For example: > > > > Between 8:06:55 PM and 8:21:36 PM, exceptions are: > > > > 1) Request says it is coming from leader, but we are the leader: > > update.distrib=FROMLEADER&distrib.from=HOSTB_ca_1_ > 1456430020/&wt=javabin&version=2 > > > > 2) org.apache.solr.common.SolrException: Request says it is coming > from > > leader, but we are the leader > > > > 3) org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: Tried one server > for read > > operation and it timed out, so failing fast > > > > 4) null:org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: Tried one server > for read > > operation and it timed out, so failing fast > > > > 5) org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: Tried one server > for read > > operation and it timed out, so failing fast > > > > 6) null:org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: Tried one server > for read > > operation and it timed out, so failing fast > > > > 7) org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: No live > SolrServers > > available to handle this request. Zombie server list: > > [HOSTA_ca_1_1456429897] > > > > 8) null:org.apache.solr.common.SolrException: > > org.apache.solr.client.solrj.SolrServerException: No live > SolrServers > > available to handle t
