On 04/05/11 13:12, Kenneth Kalmer wrote:
Hi everyone
I'd like to propose an small adjustment to the way ruote-amqp works
before I push, package and release a new ruote-amqp version (2.2.1).
Since users would need to rewrite code wouldn't this be a major version change?
http://docs.rubygems.org/read/chapter/7
section 6.3 bullet point 3
(gotta love the URL/section number mismatch there ;) )
Currently whenever we register an AMQP participant, we implicitly setup
the AMQP stack by calling RuoteAMQP.start! inside the initializer. This
used to be fine and mostly suitable until I had the realization that we
can register participants in one process (engine-only setup) and only
consume work items in other processes (engine+storage setup).
Sounds like an interesting division of labour.
In my specific case I register participants with ruote-kit in a
passenger stack, and run workers outside of the passenger stack with
rake tasks. I'd like to change the ParticipantProxy and Receiver classes
to NOT call RuoteAMQP.start!, and leave that up to the user. The user
can then decide where a realm AMQP connection is necessary or not, and
probably handle AMQP errors better. The connection is only required on
consumption of a workitem, or receiving replies from remote workers.
Isn't the default for RuoteAMQP to act as a (semi-)transparent proxy between
distributed engine/workers.
Certainly that's how I mainly use RuouteAMQP.
I can see your use-case but I'd argue that it's not the default?
I'm testing this locally, and if there are no solid objections I'll
push, package and release the update on Friday.
How about:
RuoteAMQP::Receiver.new( $engine, :launchitems => true, :amqp_listen => true )
or perhaps better:
RuoteAMQP::Receiver.new( $engine, :launchitems => :none)
with docs:
# :launchitems => :none
# # the receiver doesn't accept anything over AMQP
# # which is not started.
(Although I can't see why an engine would simply not have a Receiver registered
to it)
Similarly for the ParticipantProxy
$engine.register_participant(workitem.fields["name"],
RuoteAMQP::ParticipantProxy,
:queue => workitem.fields["queue"],
:position => -2,
:active => false )
:active => (bool) Whether the ParticipantProxy will have an active AMQP
connection. This can usefully be turned off when registration and worker
processes are different.
default true
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
--
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