ConcurrentUpdateSolrServer

[Erick Erickson <er...@gmail.com>]

OK, I'm missing something. ConcurrentUpdateSolrServer isn't robust
when reporting errors. Why can't we pass the update request to
handleError along with the exception? In the case way down at the
bottom of the Runner class we don't have access to the request, but
it'd be null in that case indicating pathology.

Then the user could override handleError and have at least the
information about what documents failed to do something. Not very
elegant, perhaps, but at least _something_ and trivial to implement.

There are much more comprehensive JIRAs to address this, but this
really seems like low-hanging fruit. Or I'm missing something
completely obvious, but a quick test worked...

Erick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: ConcurrentUpdateSolrServer

[Erick Erickson <er...@gmail.com>]

Shawn:

What I'm proposing is about the simplest thing I can imagine, with
very little risk (not to mention the time I do NOT have to put into
this issue <G>). I'm viewing it as something close to "throw away"
that I'd expect to be completely superseded by a comprehensive
solution such as has been proposed by you and others (Per?). It just
gives something to the end users whereas they have very little to do
anything with now.

But if we can have confidence we'll have a better solution for 4.2,
then we can just ignore the idea all together...

FWIW,
Erick


On Mon, Jan 21, 2013 at 12:51 PM, Shawn Heisey <so...@elyograg.org> wrote:
> On 1/21/2013 10:00 AM, Erick Erickson wrote:
>>
>> OK, I'm missing something. ConcurrentUpdateSolrServer isn't robust
>> when reporting errors. Why can't we pass the update request to
>> handleError along with the exception? In the case way down at the
>> bottom of the Runner class we don't have access to the request, but
>> it'd be null in that case indicating pathology.
>>
>> Then the user could override handleError and have at least the
>> information about what documents failed to do something. Not very
>> elegant, perhaps, but at least _something_ and trivial to implement.
>>
>> There are much more comprehensive JIRAs to address this, but this
>> really seems like low-hanging fruit. Or I'm missing something
>> completely obvious, but a quick test worked...
>
>
> See the latest comments on SOLR-3284, where I put forward an idea to address
> this.  The idea is partially implemented.
>
> Perhaps it might actually be better to use the request than just an ID like
> I have proposed.  The only hiccup I can think of is that it might be easier
> for a developer to correlate an ID (rather than the request object) to an
> update that they have made.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: ConcurrentUpdateSolrServer

[Shawn Heisey <so...@elyograg.org>]

On 1/21/2013 10:00 AM, Erick Erickson wrote:
> OK, I'm missing something. ConcurrentUpdateSolrServer isn't robust
> when reporting errors. Why can't we pass the update request to
> handleError along with the exception? In the case way down at the
> bottom of the Runner class we don't have access to the request, but
> it'd be null in that case indicating pathology.
>
> Then the user could override handleError and have at least the
> information about what documents failed to do something. Not very
> elegant, perhaps, but at least _something_ and trivial to implement.
>
> There are much more comprehensive JIRAs to address this, but this
> really seems like low-hanging fruit. Or I'm missing something
> completely obvious, but a quick test worked...

See the latest comments on SOLR-3284, where I put forward an idea to 
address this.  The idea is partially implemented.

Perhaps it might actually be better to use the request than just an ID 
like I have proposed.  The only hiccup I can think of is that it might 
be easier for a developer to correlate an ID (rather than the request 
object) to an update that they have made.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org