Autosuggest help
Hi, We need to use auto suggest click stream data in Auto suggestion . How we can achieve this ? Currently we are using suggester for auto suggestions . Regards, Midas
Re: solr tika extraction video creation date problem (hours ahead)
Sounds like timezone normalization issue. Possibly at Tika stage. Check what your SOLR_TIMEZONE variable set to. Not sure in which file. Regards, Alex On Thu, Apr 4, 2019, 12:50 AM Where is Where, wrote: > Hello , I was following the instruction > > https://lucene.apache.org/solr/guide/7_1/uploading-data-with-solr-cell-using-apache-tika.html > to upload files with metadata stored and indexed in solr. I was checking > the extracted creation date ( attr_meta_creation_date ), for image, jpg > etc, the creation dates are correct but all creation dates for video are 11 > hours ahead of the actual creation date. (The dates are correct when viewed > in other applications) It causes problem with searching due to this > inconsistency. Any idea is much appreciated. Thanks! >
Re: NestPathField
Hi all, I've found that NestPathField fieldType in the solr 8.0.0 configuration are related to https://issues.apache.org/jira/browse/SOLR-12768 which is under https://issues.apache.org/jira/browse/SOLR-12298 So answering to my own question, NestPathField is related to the ability to index deeply nested objects, but this is still under development. I write here just to not leave a question without response for the future readers, Best regards, Vincenzo On Wed, Apr 3, 2019 at 11:10 AM Vincenzo D'Amore wrote: > Hi all, > > I've found NestPathField fieldType in the solr 8.0.0 configuration. > But looking in the documentation I haven't found anything. > Just curious, someone have time to share something about? > For example explain how to use this? > > Best regards, > Vincenzo > > -- > Vincenzo D'Amore > > -- Vincenzo D'Amore
Re: high cpu threads (solr 7.5)
It hasn’t been addressed by any Java 8 releases that I know of. See: https://issues.apache.org/jira/browse/SOLR-13349 The work-around in Solr is trivial, see the patch so it’d be simple to patch/compile on your own. It will be released in a Solr 7.7.2 and Solr 8.1 or later, neither of which have been released yet. Or move to Java 9 or later. > On Apr 3, 2019, at 4:39 PM, Hari Nakka wrote: > > We are noticing high CPU utilization on below threads. Looks like a known > issue with. (https://github.com/netty/netty/issues/327) > > But not sure if this has been addressed in any of the 1.8 releases. > > Can anyone help with this? > > > Version: solr cloud 7.5 > > OS: CentOS 7 > > JDK: Oracle JDK 1.8.0_191 > > > > > > "qtp574568002-3821728" #3821728 prio=5 os_prio=0 tid=0x7f4f20018000 > nid=0x4996 runnable [0x7f51fc6d8000] > > java.lang.Thread.State: RUNNABLE > >at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > >at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > >at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > >at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > >- locked <0x00064cded430> (a sun.nio.ch.Util$3) > >- locked <0x00064cded418> (a > java.util.Collections$UnmodifiableSet) > >- locked <0x00064cdf6e38> (a sun.nio.ch.EPollSelectorImpl) > >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > >at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > >at > org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:396) > >at > org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:333) > >at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357) > >at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181) > >at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) > >at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) > >at > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) > >at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) > >at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) > >at java.lang.Thread.run(Thread.java:748)
Re: Solr indexing with Tika DIH local vs network share
Thank you Erick, this is very helpful! -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Strange behaviour building a query: SynonymQuery
Hi all, This is my first question in this forum, i'm newbye with Solr so I would be very glad if someone can resolve my doubt. We are evaluating new version of Solr 8 The problem is that when we build a query using WordDelimiterFilterFactory with preserveOriginal = 1, the parsed query has a behaviour not expected. The example could be: /name:(Whatever 7893GHT23)/ The parsed query returns: /name:whatever Synonym(name:7893 name:7893ght23) name:ght name:23/ The expected parsed query must be: /name:whatever Synonym(name:7893 name:7893ght23 name:ght name:23)/ We have tried to use synonymQueryStyle attribute with differents values in TypeField without success, always get only two terms!!! / / We have an old Solr (version 3.6), that builds the query properly: /name:whatever (name:7893ght23 name:7893 name:ght name:23)/ It would be great if anyone knows what could be happen Thanks in advance!!! -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Strange behaviour building a query: SynonymQuery
Hi all! It's solved! I have seen that we are using a deprecated version! Use WordDelimiterGraphFilterFactory instead of WordDelimiterFilterFactory solves the problem https://lucene.apache.org/solr/guide/7_2/filter-descriptions.html#word-delimiter-filter https://lucene.apache.org/solr/guide/7_2/filter-descriptions.html#word-delimiter-graph-filter name:whatever (name:7893ght23 (+name:7893 +name:ght +name:23)) Regards -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Strange behaviour building a query: SynonymQuery
Thanks for letting us know! > On Apr 4, 2019, at 8:40 AM, rodio wrote: > > Hi all! > > It's solved! > > I have seen that we are using a deprecated version! > > Use WordDelimiterGraphFilterFactory instead of WordDelimiterFilterFactory > solves the problem > > https://lucene.apache.org/solr/guide/7_2/filter-descriptions.html#word-delimiter-filter > https://lucene.apache.org/solr/guide/7_2/filter-descriptions.html#word-delimiter-graph-filter > > > name:whatever (name:7893ght23 (+name:7893 +name:ght +name:23)) > > Regards > > > > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Proper type(s) for adding a DatePointField value [was: problems with indexing documents]
One difficulty is that the documentation of
SolrInputDocument.addField(String, Object) is not at all specific.
I'm aware of SOLR-2298 and I accept that the patch is an improvement,
but still...
@param value Value of the field, should be of same class type as
defined by "type" attribute of the corresponding field in
schema.xml.
The corresponding 's 'type' attribute is an arbitrary label
referencing the 'name' attribute of a . It could be
"boysenberry" or "axolotl". So we need to look at the 'class'
attribute of the fieldType? So, if I have in my schema:
then I need to pass an instance of DatePointField?
myDoc.addField("created", new DatePointField(bla bla));
That doesn't seem right, but go ahead and surprise me.
But I *know* that it accepts a properly formatted String value for a
field using DatePointField. So, how can I determine the set of Java
types that is accepted as a new field value for a field whose field
type's class attribute is X? And where should I have read that?
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
signature.asc
Description: PGP signature
Re: Indexing in one collection affect index in another collection
Hi all, This issue is still surfacing in the new Soir 8.0.0. Can't really figure out what is the issue, as it occurs also in system with more memory. Anyone has any further insights on this? Regards, Edwin On Fri, 15 Feb 2019 at 18:40, Zheng Lin Edwin Yeo wrote: > Hi Shawn, > > This issue is also occurring in the new Solr 7.7.0, with only the same > data size of 20 GB. > > Regards, > Edwin > > On Fri, 8 Feb 2019 at 23:53, Zheng Lin Edwin Yeo > wrote: > >> Hi Shawn, >> >> Thanks for your reply. >> >> Although the space in the OS disk cache could be the issue, but we didn't >> face this problem previously, especially in our other setup using Solr >> 6.5.1, which contains much more data (more than 1 TB), as compared to our >> current setup in Solr 7.6.0, in which the data size is only 20 GB. >> >> Regards, >> Edwin >> >> >> >> On Wed, 6 Feb 2019 at 23:52, Shawn Heisey wrote: >> >>> On 2/6/2019 7:58 AM, Zheng Lin Edwin Yeo wrote: >>> > Hi everyone, >>> > >>> > Does anyone has further updates on this issue? >>> >>> It is my strong belief that all the software running on this server >>> OTHER than Solr is competing with Solr for space in the OS disk cache, >>> and that Solr's data is getting pushed out of that cache. >>> >>> Best guess is that with only one collection, the disk cache was able to >>> hold onto Solr's data better, and that with another collection present, >>> there's not enough disk cache space available to cache both of them >>> effectively. >>> >>> I think you're going to need a dedicated machine for Solr, so Solr isn't >>> competing for system resources. >>> >>> Thanks, >>> Shawn >>> >>
Solr 6.6 and OpenJDK11
So we are having some production issues with solr 6.6 with OpenJDK 11. There are a lot of heap errors (ours was set to 10gig on a 16 gig instance) and we never encountered this until we upgraded from Oracle JDK 8 to OpenJDK 11. So is it advisable to keep it at openjdk 11 or should we downgrade to OpenJDK 8? -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: solr tika extraction video creation date problem (hours ahead)
Thanks Alex. The problem is image creation date is correct, but the video creation date is wrong (hours behind), if I set the time_zone I think the image creation date will be wrong then. wonder what the difference between image and video extraction in tika. -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
