#mcollective

[mcollective-puppet-agent] ploubser closed pull request #1: Show details of whats changed in puppet summary report (master...master) http://git.io/saudow

[mcollective-puppet-agent] richardc pushed 2 new commits to master: http://git.io/eWl_Kg

mcollective-puppet-agent/master 7f69671 tczekajlo: Add whitelist and blacklist for resource name

mcollective-puppet-agent/master a76c2d5 Richard Clamp: Merge pull request #29 from tczekajlo/master...

[mcollective-puppet-agent] richardc closed pull request #29: Whitelist and blacklist for resource name (master...master) http://git.io/1KvoQQ

Can I specify -F and -I on mco with an OR relationship?

no, just use the fqdn fact in -F

or hostname or whatever

Volcane, thanks.

Hello everyone. Could anyone comment on the request throughput of mcollectived? I started reading through the daemon code and it seems it only uses a single thread for receiving and processing incoming messages from rabbitmq/stomp.

Good question. I was wondering that myself.

single thread consumes messages, starts threads to handle them

you wouldnt want to do very high concurrency - ie. its not a general work queue type handler in default config

but coiuld be, where you can start dedicated processes to consume the queue for a specific daemon and it will load share cross the processes

Volcane: right. That's what I was thinking, IIUC multiple daemons consuming the queue and thus sharing the load. You think this makes sense for the mcollective project as a whole or it's just a domain-specific solution?

mco can be deployed in such a manner but its not exactly turn key, libraries support it

Volcane: sorry, what do you mean by turn key?

deploying it in that way - dedicated process etc - isnt in the shipped daemon, the libraries can do it but the shipped daemon is tailored to the admin tasks use case

but you think it makes sense to modify the daemon in such a manner?

instead of a single thread processing messages, it could have several

read what i said

a single thread reads the message

then makes a new thread to process it

then goes back to reading messages

messages are handled in parallel

its not limited to a single task at a time

I did read. The problem is that the code to spawn the thread to process it takes a non-zero amount of time. This reduces the throughput of the daemon