The time skew/TZ is really the 'other half' of what the patch would/should ultimately be.
Since the current patch only deals with dist responses, it will be perfectly happy to receive facet_dates that have been generated in sync with the requester. I'm not really familiar with the distributed sending part of the code, but I would suspect that whatever component is delegated the task of fanning out shard requests would be a good candidate for 'owning' the marking of 'NOW' and adding the appropriate parameters to send to the shards (might this be the very same FacetComponent in distributedProcess()?). Then there's the task of the remote shard digesting the new parameters and adjusting its dates accordingly. Presumably this would be handled by SimpleFacets? For facet.date.start/facet.date.end, I guess if these are/can only be relative times (is it allowed to set an explicit start/end time?), then the remote shard can simply interpret NOW as the passed-in NOW, rather than its own NOW. Are there any options for facet.date.start/end that don't involve NOW at all? Peter > Date: Fri, 8 Jan 2010 20:35:54 +0000 > From: j...@apache.org > To: solr-dev@lucene.apache.org > Subject: [jira] Commented: (SOLR-1709) Distributed Date Faceting > > > [ > https://issues.apache.org/jira/browse/SOLR-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798170#action_12798170 > ] > > Yonik Seeley commented on SOLR-1709: > ------------------------------------ > > I haven't checked the patch, but it seems like we should take a generic > approach to NOW... > The first time NOW is used anywhere in the request (and is not passed in as a > request argument), either a thread local or something in the request context > should be set to the current time. Subsequent references to NOW would yield > the first value set. > This would allow NOW to be referenced more than once in the same request with > consistent results. > > Passing in "NOW" as a request parameter would simply set it explicitly... the > question is, who (which solr component) should be responsible for that? > > > Distributed Date Faceting > > ------------------------- > > > > Key: SOLR-1709 > > URL: https://issues.apache.org/jira/browse/SOLR-1709 > > Project: Solr > > Issue Type: Improvement > > Components: SearchComponents - other > > Affects Versions: 1.4 > > Reporter: Peter Sturge > > Priority: Minor > > Attachments: FacetComponent.java, ResponseBuilder.java > > > > > > This patch is for adding support for date facets when using distributed > > searches. > > Date faceting across multiple machines exposes some time-based issues that > > anyone interested in this behaviour should be aware of: > > Any time and/or time-zone differences are not accounted for in the patch > > (i.e. merged date facets are at a time-of-day, not necessarily at a > > universal 'instant-in-time', unless all shards are time-synced to the exact > > same time). > > The implementation uses the first encountered shard's facet_dates as the > > basis for subsequent shards' data to be merged in. > > This means that if subsequent shards' facet_dates are skewed in relation to > > the first by >1 'gap', these 'earlier' or 'later' facets will not be merged > > in. > > There are several reasons for this: > > * Performance: It's faster to check facet_date lists against a single map's > > data, rather than against each other, particularly if there are many shards > > * If 'earlier' and/or 'later' facet_dates are added in, this will make the > > time range larger than that which was requested > > (e.g. a request for one hour's worth of facets could bring back 2, 3 or > > more hours of data) > > This could be dealt with if timezone and skew information was added, and > > the dates were normalized. > > One possibility for adding such support is to [optionally] add 'timezone' > > and 'now' parameters to the 'facet_dates' map. This would tell requesters > > what time and TZ the remote server thinks it is, and so multiple shards' > > time data can be normalized. > > The patch affects 2 files in the Solr core: > > org.apache.solr.handler.component.FacetComponent.java > > org.apache.solr.handler.component.ResponseBuilder.java > > The main changes are in FacetComponent - ResponseBuilder is just to hold > > the completed SimpleOrderedMap until the finishStage. > > One possible enhancement is to perhaps make this an optional parameter, but > > really, if facet.date parameters are specified, it is assumed they are > > desired. > > Comments & suggestions welcome. > > As a favour to ask, if anyone could take my 2 source files and create a > > PATCH file from it, it would be greatly appreciated, as I'm having a bit of > > trouble with svn (don't shoot me, but my environment is a Redmond-based os > > company). > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > _________________________________________________________________ Do you have a story that started on Hotmail? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
