Clob transformer not working in DIH

Hi, I am using solr 5.4.1. Here I am using dataimport handler to index data with SQL Server. I am using CLOB transformer to convert clob value to string. Indexing is working fine but clob transformation is not working. Expected string value is not coming for clob column. There is no error or

Re: Very long young generation stop the world GC pause

Your gun (not quite smoking yet, we still need the fingerprints) is this: [Times: user=0.00 sys=94.28, real=97.19 secs] Normal GC pauses are generally almost entirely user CPU, very short and multiprocessor. Something else is sometimes happening with either the JVM or OS which is causing this

Re: The state of Solr 5. Is it in maintenance mode only?

: On the 5.x front I wasn't expecting 5.6 release now that we have 6.x but : was simply surprised to see fix for 4.x and not for 5.x. As Shawn mentioned: jira issues might have inccorrect fixVersion info if people don't pay enough attention when resolving (especially with dups/invalid) but

"on deck" searcher vs warming searcher

Is there a difference between an "on deck" searcher and a warming searcher? >From what I've read, they sound like the same thing. -- View this message in context: http://lucene.472066.n3.nabble.com/on-deck-searcher-vs-warming-searcher-tp4309021.html Sent from the Solr - User mailing list

Re: Solr seems to reserve facet.limit results

Markus Jelsma wrote: > I tried the overrequest ratio/count and set them to 1.0/0 . Odd enough, > with these settings high facet.limit and extremely high facet.limit are > both up to twice as slow as with 1.5/10 settings. Not sure if it is the right explanation for

RE: prefix query help

I think this will work. Ill try it tomorrow and let you know. Thanks for the help Eric and Shawn Kris -Original Message- From: Erik Hatcher [mailto:erik.hatc...@gmail.com] Sent: Thursday, December 8, 2016 2:43 PM To: solr-user@lucene.apache.org Subject: Re: prefix query help It’s hard

Re: prefix query help

It’s hard to tell how _exact_ to be here, but if you’re indexing those strings and your queries are literally always -MM, then do the truncation of the actual data into that format or via analysis techniques to index only the -MM piece of the incoming string. But given what you’ve

Re: prefix query help

yes I did attach rather than paste sorry.   Ok heres an actual, truncated, example of the metatag.date field contents in solr. NONE-NN-NN is the default setting.   doc 1 " metatag.date ": [   "2016-06-15T14:51:04Z" ,   "2016-06-15T14:51:04Z"     ]   doc 2 "

Re: prefix query help

On 12/8/2016 10:02 AM, KRIS MUSSHORN wrote: > > Here is how I have the field defined... see attachment. You're using a tokenized field type. For the kinds of queries you asked about here, you want to use StrField, not TextField -- this type cannot have an analysis chain and indexes to one token

Re: prefix query help

Kris - To chain multiple prefix queries together: q=({!prefix f=field1 v=‘prefix1'} {!prefix f=field2 v=‘prefix2’}) The leading paren is needed to ensure it’s being parsed with the lucene qparser (be sure not to have defType set, or a variant would be needed) and that allows multiple {!…}

Re: prefix query help

Here is how I have the field defined... see attachment.     - Original Message - From: "Erick Erickson" To: "solr-user" Sent: Thursday, December 8, 2016 10:44:08 AM Subject: Re: prefix query help You'd probably be better off

Re: IndexWriter exception

I believe you may want to look into commit frequency as pointed by Eric to resolve this issue. If you committing too often, it may keep opening the multiple searchers and running into race conditions. Thanks, Susheel On Thu, Dec 8, 2016 at 10:49 AM, Alexandre Drouin <

RE: Solr seems to reserve facet.limit results

Thanks Chris, Toke, I tried the overrequest ratio/count and set them to 1.0/0 . Odd enough, with these settings high facet.limit and extremely high facet.limit are both up to twice as slow as with 1.5/10 settings. Even successive calls don't seem to 'warm anything up`. Anyone with an

Re: Solr node not found in ZK live_nodes

This happens some time that one of the node goes down but then it gets registered as Leader/Active. Does the Cloud View shows anything about this node (Recovering/Down/Recovery Failed etc.) and are you able to perform query to just this shard/node directly? Susheel On Wed, Dec 7, 2016 at 10:13

RE: IndexWriter exception

I checked my source control history and "6" was the original value that was checked-in. I'll investigate lowering this value in our next iteration. Thanks for the hint. Alexandre Drouin -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: December 6, 2016

Re: prefix query help

You'd probably be better off indexing it as a "string" type given your expectations. Depending on the analysis chain (do take a look at admin/analysis for the field in question) the tokenization can be tricky to get right. Best, Erick On Thu, Dec 8, 2016 at 7:18 AM, KRIS MUSSHORN

prefix query help

Im indexing data from Nutch into SOLR 5.4.1. I've got a date metatag that I have to store as text type because the data stinks. It's stored in SOLR as field metatag.date. At the source the dates are formatted (when they are entered correctly ) as -MM-DD   q=metatag.date:2016-01* does

Re: Very long young generation stop the world GC pause

On 12/8/2016 1:06 AM, forest_soup wrote: > As you can see in the gc log, the long GC pause is not a full GC. It's a > young generation GC instead. > In our case, full gc is fast and young gc got some long stw pause. > Do you have any comments on that, as we usually believe full gc may cause >

Re: Very long young generation stop the world GC pause

Disable all the G1GC tuning your are doing except for ParallelRefProcEnabled G1GC is an adaptive algorithm and would keep tuning to reach the default pause goal of 250ms which should be good for most of the applications. Can you also tell us how much RAM you have on your machine and if you have

Solr cannot provide index service after a large GC pause but core state in ZK is still active

Hi Erick, Mark and Varun, I'll use this mail thread tracking the issue in https://issues.apache.org/jira/browse/SOLR-9829 . @Erick, for your question: I'm sure the solr node is still in the live_nodes list. The logs are from solr log. And the most root cause I can see here is the IndexWriter

Re: Very long young generation stop the world GC pause

Besides, will those JVM options make it better? -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=10  -- View this message in context: http://lucene.472066.n3.nabble.com/Very-long-young-generation-stop-the-world-GC-pause-tp4308911p4308937.html Sent from the Solr - User mailing list

Encryption to Solr stored fields – Using Custom Codec Lucene JIRA -6966

Hello, I am trying to experiment with my solr indexes with the patch open on Apache JIRA - Codec for index-level encryption (LUCENE-6966). https://issues.apache.org/jira/browse/LUCENE-6966. I am currently trying to test this Custom codec with

IllegalArgumentException: lucene file does not exist

Hi All, I'm using Solr 6.3.0 to build a large index (around 700+GB). Everything went well on a normal PC, But when I moved to an HPC ( High Performance Computing cluster) solr generates the following exception, - java.lang.:

Re: Very long young generation stop the world GC pause

As you can see in the gc log, the long GC pause is not a full GC. It's a young generation GC instead. In our case, full gc is fast and young gc got some long stw pause. Do you have any comments on that, as we usually believe full gc may cause longer pause, but young generation should be ok?