On Wed, Sep 16, 2009 at 10:09 AM, Jordan Ritter <[email protected]> wrote:
>
> On Sep 15, 2009, at 5:50 PM, John Mettraux wrote:
>
> (2) Figured out how to override wfidgen and errorjournal today (very
>
> easy!). in doing so though, I realized that the other subsystems rely
>
> on wfidgen's mkdir(work), so I have to manually mkdir(work).
>
> Yes, you have to provide a #split method in your WfidGenerator
> implementation. FsStorage for example uses it to determine its
> subdirectories structure.
>
> OK, so my WfidGenerator is derived from HashWfidGenerator, and I overrode
> generate, + context= (to prevent last_save/etc). so, technically, I do have
> a split() method (inherited from yours) -- but it seems to me that the
> FsStorageEngine itself should be pre-creating that directory before it calls
> build_*.
> In my case, I use ruote-dm, and (as you know) DmStorageEngine derives from
> FsStorageEngine, overriding only the expression storage -- which leaves
> everything else still using filesystem storage. Given that any build_*
> might be arbitrarily overridden, shouldn't either (1) the engine be
> responsible for creating that dir, or (2) each "service" that relies on it
> should verify it's there (not very DRY)?
Hello,
the split method is not related to the creation of the "work"
directory. FsStorageEngine is independent from any WfidGenerator when
creating its hierarchy under "work" (mkdir -p).
Creating directories is not a responsibility of the engine, it's up to
the services and they tend to not trust each others for such matters.
> Questions:
>
> (1) Can you explain the practical use for the inclusion of the word
>
> "engine" in the 'engine|wfid|expid' wfid/expid/etcs?
>
> Was thinking of two completely different engines sharing the same
> storage (not a very good idea perhaps) or simply 1 engine per
> sub-organization and workitems zipping around. May help routing
> workitems back to their origin engine.
>
> Hmm. Where's the engine name set? For me, I think I'd rather set it to "1"
> as a quick optimization eliminating redundant data.
You can change the engine_id via the option :engine_id at engine initialization.
> (2) Any idea why whenever I "return" from a block participant (due to
>
> a detected error condition usually), I get this sort of error (my own
>
> formatting, but you get the gist):
>
> 2009-09-15 13:20:08 ERROR </engine|20090911-bokishineki_44|
>
> 0_0_0_0_7_2_0_0_0> ThreadError: return can't jump across threads
>
> ({:workitem=>#<Ruote::Workitem:0x107500cc8 .... })
>
> OK,
>
> try to run that piece of Ruby code :
>
> ---8<---
> Thread.new do
> return :nada
> end.join
> --->8---
>
> Since block participant, by default, lets the engine wraps its consume
> action in a Thread, that triggers your error.
>
> Ohh, is that the synchronous/synchronized flag I saw somewhere?
Not at all. The body of the method that triggered a thread might be
long gone, so Ruby has no way to return there, and thus complains.
> I learned that the hard way a couple of years ago. I know the pain. (I
> love the short-circuit coding as well).
>
> Ahh crap, seriously? Man.. I have an arbitrary # short-circuit exit
> conditions, and (useful) logging for each error.. I guess a kludge would be
> to accumulate errors up until I get to do_the_job, but that's not very
> practical since there are also arbitrary non-error exit conditions.
> Is there *anything* I can do to exit the callback early? Maybe a break
> since it's inside a closure? Or is there some neato ruote-ism we can
> shoehorn in?
No ruote-ism here, plain Ruby. Avoid the use of return in your block
participant.
OR
---8<---
bp = engine.register_participant :toto do |workitem|
return if $wrong
puts "got workitem"
end
bp.do_not_thread = true
--->8---
which prevents the Thread wrapping BUT blocks the whole ruote engine
while your participant is handling its workitems (it means all the
processes are waiting, and you really have to trust your body of code
to return the hand to the engine at some point, ...)
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 [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
-~----------~----~----~----~------~----~------~--~---
