issue deleting processes in ruote-rest + DmPersistedEngine

1 view
Skip to first unread message

Gonzalo

unread,
Aug 29, 2009, 7:19:10 PM8/29/09
to Ruote (OpenWFEru) users
Hi all,

Two days ago I set up ruote-rest to use DmPersistedEngine. I added the
following lines to 'conf/engine.rb'

require 'dm-core'
DataMapper.setup(:default, {
:adapter => "postgres",
:database => "ruoterest_development",
:username => "postgres",
:password => "postgres",
:host => "localhost"
})
require 'openwfe/extras/engine/dm_engine'
engine_class = OpenWFE::Extras::DmPersistedEngine


Then I started the engine and everything worked pretty fine. But today
I found an issue. Here is how I got it:

1. Start the engine.
2. Launch some processes (I tested this with default process in /
processes form)
3. Stop and start the engine again.
4. Request any of the processes previously launched and try to delete
it.

Then the issue shows up with the following output:

uninitialized constant OpenWFE::Definition
/Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
dependencies.rb:440:in `load_missing_constant'
/Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
dependencies.rb:80:in `const_missing'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/extras/
expool/dm_expstorage.rb:213:in `fetch_root'
/Library/Ruby/Gems/1.8/gems/dm-core-0.9.11/lib/dm-core.rb:181:in
`repository'
/Library/Ruby/Gems/1.8/gems/dm-core-0.9.11/lib/dm-core/repository.rb:
44:in `scope'
/Library/Ruby/Gems/1.8/gems/dm-core-0.9.11/lib/dm-core.rb:181:in
`repository'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/extras/
expool/dm_expstorage.rb:209:in `fetch_root'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/expool/
expstorage.rb:268:in `fetch_root'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/expool/
expressionpool.rb:454:in `fetch_root'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/expool/
expressionpool.rb:306:in `cancel_process'
/Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/engine/
expool_methods.rb:45:in `cancel_process'
/Users/gonzalo/Stuff/Ruby/ruote-rest/lib/res/processes.rb:133:in
`call'
[...]

It seems that ruote isn't able to deal properly with "old" processes
persisted with DmPersistedEngine. Nevertheless, creating and deleting
processes without stopping the engine at any moment works well.

Best regards.
Gonzalo.

John Mettraux

unread,
Aug 29, 2009, 9:00:05 PM8/29/09
to openwfe...@googlegroups.com
On Sun, Aug 30, 2009 at 8:19 AM, Gonzalo<gonzalo....@gmail.com> wrote:
>
> (...)

>
> Then I started the engine and everything worked pretty fine. But today
> I found an issue. Here is how I got it:
>
> 1. Start the engine.
> 2. Launch some processes (I tested this with default process in /
> processes form)
> 3. Stop and start the engine again.
> 4. Request any of the processes previously launched and try to delete
> it.
>
> Then the issue shows up with the following output:
>
> uninitialized constant OpenWFE::Definition
> /Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
> dependencies.rb:440:in `load_missing_constant'
> /Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
> dependencies.rb:80:in `const_missing'
> /Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/extras/
> expool/dm_expstorage.rb:213:in `fetch_root'

Hello Gonzalo,

thanks for testing the dm expstorage.

I have committed a potential fix

http://github.com/jmettraux/ruote/commit/97bdc8c7103f6e61a2f3ea67fdf3f5ead43a0e8f

Maybe this expstorage is a bit too experimental for ruote 0.9.x. It's
much more tested for ruote 2.0 though.

Tell me how it works for you.

A quick question, I'm curious ;) Why are you guys trying to move to
rdbms persistence ?


Thanks a lot for the report, cheers,

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

Gonzalo

unread,
Aug 30, 2009, 6:39:05 AM8/30/09
to Ruote (OpenWFEru) users
Hi John,

I've just tested ruote-rest with your patch and everything seems to
work great now! Thank you very much.

We haven't decided yet what expool persistence engine to use. In our
development we use the default fs engine. We will probably move to
tokyo cabinet in the future. The tests with DataMapper persistence
engine are just my own curiosity :)


Thanks again for a great-quick fix!
Regards.
Gonzalo.





On Aug 30, 3:00 am, John Mettraux <jmettr...@openwfe.org> wrote:
> On Sun, Aug 30, 2009 at 8:19 AM, Gonzalo<gonzalo.llore...@gmail.com> wrote:
>
> > (...)
>
> > Then I started the engine and everything worked pretty fine. But today
> > I found an issue. Here is how I got it:
>
> > 1. Start the engine.
> > 2. Launch some processes (I tested this with default process in /
> > processes form)
> > 3. Stop and start the engine again.
> > 4. Request any of the processes previously launched and try to delete
> > it.
>
> > Then the issue shows up with the following output:
>
> > uninitialized constant OpenWFE::Definition
> > /Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
> > dependencies.rb:440:in `load_missing_constant'
> > /Library/Ruby/Gems/1.8/gems/activesupport-2.3.3/lib/active_support/
> > dependencies.rb:80:in `const_missing'
> > /Users/gonzalo/Stuff/Ruby/ruote-rest/vendor/ruote/lib/openwfe/extras/
> > expool/dm_expstorage.rb:213:in `fetch_root'
>
> Hello Gonzalo,
>
> thanks for testing the dm expstorage.
>
> I have committed a potential fix
>
>  http://github.com/jmettraux/ruote/commit/97bdc8c7103f6e61a2f3ea67fdf3...

John Mettraux

unread,
Aug 30, 2009, 6:43:20 AM8/30/09
to openwfe...@googlegroups.com
On Sun, Aug 30, 2009 at 7:39 PM, Gonzalo<gonzalo....@gmail.com> wrote:
>
> We haven't decided yet what expool persistence engine to use. In our
> development we use the default fs engine. We will probably move to
> tokyo cabinet in the future. The tests with DataMapper persistence
> engine are just my own curiosity :)

Nice !

BTW, if I could help you to migrate to ruote 2.0, what would you need
? Would you need the equivalent of ruote-rest ?

Gonzalo Suarez

unread,
Aug 31, 2009, 6:19:21 AM8/31/09
to openwfe...@googlegroups.com
Hi John,

As you might know, our backend development is mainly focused on
route-rest. As Nando and I told you before, we've done some
improvements on the authentication layer, aka "Spanish Authentication"
:-)

On the other hand, we have extended ArWorkitem so that it can handle
users, groups and authorization primitives: "pick, release, delegate
(to_group and to_user) and undo (a kind of wi_fields rollback to the
'consume' state)". Last week, Nando enabled Jabber PubSub capabilities
to these operations and to ArParticipant's consume, thus avoiding the
need to poll the resource "/workitems" from the client.

The original ArWorkitem has been left unharmed, as these authorization
behaviors are dinamically loaded after ruote-rest/lib/res/workitems.rb
performs a find_workitem, using ActiveRecord's "after_find" callback:

---- begin snip ----

class ArWorkitem
....
def after_find

unless self.extended_behaviors.nil?
require 'openwfe/extras/misc/behaviors'
self.extended_behaviors.split(',').each do |extension|
self.class_eval "include OpenWFE::Extras::Behaviors::#{extension}"
end
end
end

--- end snip ---

As written above, these "behaviors" are just auth methods and pubsub
stuff, used by our two new participants:

---- begin snip ---
class ArAuthParticipant < ArParticipant
...
def consume
...
ArWorkitem.from_owfe_workitem(workitem, @store_name, @assigned_to,
@owner_group, nil, ['ArSimpleAuthorization'])
...

class JabberArAuthParticipant < ArAuthParticipant
...
def consume
...
ArWorkitem.from_owfe_workitem(workitem, @store_name, @assigned_to,
@owner_group, @pubsub_uuid, ['ArPubSubAuthorization'])
...

---- end snip ---

Accordingly, we had to add more fields to the original ar_workitems table.

Worth mentioning is the extension we've made to Kenneth's
extras/misc/jabber_common.rb so that it includes methods to deal with
a PubSub service, as well as the changes made to xmpp4r-simple itself.

We really don't know if this approach is correct, given that we have
closely bound ArWorkitem with the REST layer, but all in all, this is
the famous "last mile" that we love so much about your project. We'll
post the complete patches during the week so that you can give us some
feedback, via mailing-list or #ruote irc.

So, answering your question, since we've developed participants that
are so closely coupled with the REST layer, it would be great that
ruote-kit would be compatible with them, or that you could tell us how
to adapt them to the upcoming changes. We have in mind that
Ruote2.0/ruote-kit is the way to go, but we are not in a hurry. Our
next few internal milestones will be still based on ruote-rest, but in
the meantime we will continue contributing to this community and
refactoring our code.

Best regards,
//Gonzalo and Nando


2009/8/30 John Mettraux <jmet...@openwfe.org>:

Reply all
Reply to author
Forward
0 new messages