Update documentation for listener configuration

[prolic]

• how to configure the listeners
• make an example with serialization and encoding (perhabs HumusAmqpDemoModule)
• perhabs deprecate the callback manager and callback configuration??

[jackdpeterson]

(thumbs up) for this documentation request. I'm now on pg. 38 [pdf](1.7.8 - Set up the consumer) of the documentation and I'm unclear why one would end up configuring a lot of individual consumer callback classes. I can understand if someone were say implementing consumers across different languages for reasons of performance or otherwise (e.g., say an image optimizer) in C or C++; however, everything here is in one place with one shared global configuration.

It seems like this should be delegated out to something else like a factory that would instantiate the right callback but I'm not exactly seeing how this is done at the moment with the module to date. Even the RPC server seems like the same approach with a different flavor.

With the way things are wouldn't one need to instantiate a new instance of a different consumer for each consuming bit of functionality?

e.g.
php public/index.php humus amqp consumer image-processor
php public/index.php humus amqp consumer email-notifier
php public/index.php humus amqp consumer daily-report-thingy

In the ZF2 model it would seem to make more sense to start up a consumer like
php public/index.php humus amqp consumer my-project-name.

Then you would run that N number of times for each free thread [or some other mechanism]. Each of those consumer instances would be the same and could handle all types of configured requests across N number of queues.

Any thoughts would be much appreciated as I'm working my way through this documentation to learn how to do this.

Thanks again!

[prolic]

Hi,

thanks for your support. A consumer is a process. So if you need multiple processes, you need to start multiple consumers. To start all consumers needed for your application, I use supervisord. I also created a SupervisorModule for ZF2 that integrates with HumusAMQPModule.
With the supervisor you can do stuff like "run all my consumers, some of them in parallel, keep attention that they don't consume too much memory and restart them, it they die".

[prolic]

About callbacks: You can reuse them accross consumers, you can have a logger-callback that is attached to all consumers, refactoring plannings are towards using a listener aggregate instead of a single callback.