Customer scorer thread safety


(Aidan Skinner) #1

Hi,

I'm implementing a custom scorer plugin which involves calling out to a
separate process (in this case R) so needs to manage a TCP socket and I was
wondering if I'd understood the lifecycle and contract right
for AbstractSearchScript (well, AbstractFloatSearchScript), AIUI:

There's 1 instance per shard (and the live for the life time of the
shard?), created from the factory

and

runAsFoo needs to be threadsafe but not fully reentrant

Is that right? I'm not entirely sure I followed the logic up to
shardOperation correctly...

Thanks,

  • Aidan

(Aidan Skinner) #2

(Urgh, sorry, subject should be custom scorer, I've clearly not had enough
coffee)

  • Aidan

(Colin Dellow) #3

On Tuesday, 10 July 2012 06:40:21 UTC-4, Aidan Skinner wrote:

Hi,

I'm implementing a custom scorer plugin which involves calling out to a
separate process (in this case R) so needs to manage a TCP socket and I was
wondering if I'd understood the lifecycle and contract right
for AbstractSearchScript (well, AbstractFloatSearchScript), AIUI:

There's 1 instance per shard (and the live for the life time of the
shard?), created from the factory

I haven't looked at the ES code, but my experience is 1 instance of the
factory per shard, with lifetime equal to the shard's lifetime. And then
one instance of the script per query per shard, with lifetime equal to the
lifetime of the query.


(Aidan Skinner) #4

On Tuesday, July 10, 2012 4:02:49 PM UTC+1, Colin Dellow wrote:

On Tuesday, 10 July 2012 06:40:21 UTC-4, Aidan Skinner wrote:

Hi,

I'm implementing a custom scorer plugin which involves calling out to a
separate process (in this case R) so needs to manage a TCP socket and I was
wondering if I'd understood the lifecycle and contract right
for AbstractSearchScript (well, AbstractFloatSearchScript), AIUI:

There's 1 instance per shard (and the live for the life time of the
shard?), created from the factory

I haven't looked at the ES code, but my experience is 1 instance of the
factory per shard, with lifetime equal to the shard's lifetime. And then
one instance of the script per query per shard, with lifetime equal to the
lifetime of the query.

That doesn't quite fit with what I've observed with the debugger and
logging but I'm prepared to believe I'm doing it wrong :slight_smile:

Any idea about threadsafety of runAs?

  • Aidan

(Aidan Skinner) #5

On Tuesday, July 10, 2012 10:15:48 PM UTC+1, Aidan Skinner wrote:

On Tuesday, July 10, 2012 4:02:49 PM UTC+1, Colin Dellow wrote:

On Tuesday, 10 July 2012 06:40:21 UTC-4, Aidan Skinner wrote:

Hi,

I'm implementing a custom scorer plugin which involves calling out to a
separate process (in this case R) so needs to manage a TCP socket and I was
wondering if I'd understood the lifecycle and contract right
for AbstractSearchScript (well, AbstractFloatSearchScript), AIUI:

There's 1 instance per shard (and the live for the life time of the
shard?), created from the factory

I haven't looked at the ES code, but my experience is 1 instance of the
factory per shard, with lifetime equal to the shard's lifetime. And then
one instance of the script per query per shard, with lifetime equal to the
lifetime of the query.

That doesn't quite fit with what I've observed with the debugger and
logging but I'm prepared to believe I'm doing it wrong :slight_smile:

Any idea about threadsafety of runAs?

I hassled kimchy on irc, turns out runAs doesn't need to be threadsafe and
there's one instance of the search script per shard per query.

  • Aidan (answering his own mail like a... not a boss... something else)

(system) #6