[ruote:2190] participant favouring a specific worker

[John Mettraux]

Hello,

on IRC I had a chat with Avishai and he asked me about how to make
sure the "dispatch to participant" work is always handled by the same
participant, for data locality reasons.

There could be two techniques. For the first one, I added a reject
method to LocalParticipant :

http://github.com/jmettraux/ruote/commit/7b97228c9f752083977cfc8e4d600668d3731884

a [local] participant can thus reject a workitem. As seen in the test
case, it's perhaps a good idea to flag the workitem with a reject
count.

It's probably not the best technique, since it requires at least four
operations (dispatch - handle - dispatch - handle) instead of two
(dispatch - handle).

The other technique is not the subject of a commit. It's a suggestion,
re-opening the worker class. Since the worker has this method :

---8<---
# Should always return false. Except when the message is a 'dispatch'
# and it's for a participant only available to an 'engine_worker'
# (block participants, stateful participants)
#
def cannot_handle (msg)

return false if msg['action'] != 'dispatch'

@context.engine.nil? && msg['for_engine_worker?']
end
--->8---

this re-opening could be done :

---8<---
class Ruote::Worker

def cannot_handle (msg)

return false if msg['action'] != 'dispatch'

msg['workitem']['fields']['for_host'] != current_hostname
end
end
--->8---

(IMHO it's OK for a end-user to re-open a class).

It discards the workitem (cannot_handle => true) if the hypothetical
current_hostname method returns something different than the value
found in a workitem field 'for_host'.


Best regards,

--
John Mettraux - http://jmettraux.wordpress.com

--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en

[avishai]

Well, I think it would be better to focus on controlling dispatch
locality in the broader sense then implementing something that is host
specific. After all, you may want to have the dispatch select the host
by fields other than hostname.

Perhaps a selection criteria - a boolean ruby block - would be better?
and perhaps while we're at it, maybe it's better to just add a general
dispatch hook and leave room for crazy ideas...

Avishai

[John Mettraux]

On Wed, Apr 21, 2010 at 02:50:40AM -0700, avishai wrote:
>
> Well, I think it would be better to focus on controlling dispatch
> locality in the broader sense then implementing something that is host
> specific. After all, you may want to have the dispatch select the host
> by fields other than hostname.

Sorry, this was just an example.

> Perhaps a selection criteria - a boolean ruby block - would be better?
> and perhaps while we're at it, maybe it's better to just add a general
> dispatch hook and leave room for crazy ideas...

It's just ruby code, it's easy to re-open a class.

It's not forbidden either to provide your own implementation of the ruote services.

http://github.com/jmettraux/ruote/blob/ruote2.1/lib/ruote/context.rb#L138-156

On the other hand, you could place your routing logic in your participant implementation, shared by all workers. The participant knows where the "real" participant is.

Plenty of room for crazy ideas.

Best regards,

--
John Mettraux - http://jmettraux.wordpress.com

[avishai]

> On the other hand, you could place your routing logic in your participant implementation, shared by all workers. The participant knows where the "real" participant is.
>

You mean having a participant call a participant? That's a good idea.
I should have thought of that...

Avishai

[John Mettraux]

On Thu, Apr 22, 2010 at 7:26 PM, avishai
<avishai.i...@mail.huji.ac.il> wrote:
>> On the other hand, you could place your routing logic in your participant implementation, shared by all workers. The participant knows where the "real" participant is.
>>
> You mean having a participant call a participant? That's a good idea.
> I should have thought of that...

Participants that are clients to [real] participants. Proxies, stubs,
routers, ... so many techniques.

Enjoy !

--
John Mettraux - http://jmettraux.wordpress.com