Hello,
thanks for this contribution!
Do you have a link to the module source code or can you send it
attached? We need to review a bit and check if everything is in place
(e.g., license, documentation).
For a better clarification, do the json payloads flowing via AMQP have a
structure specific for kazoo? I mean the object structure, how are the
fields name set, from the name of the columns? Is there a wrapper to
specify the command (e.g., insert, delete, select)? Or maybe you can
provide an example of such object...
Kazoo is an open source application, therefore the new module has no
barrier in getting inside kamailio repository. My questions were related
more to see if worth considering a new name.
To get it in our git repository, we expect that you or someone else from
2600hz is willing to maintain it for at least one year. You will get
write access over ssh to git repository to be able to push the new
module and commit to it in the future. I will write a separate email
directly to you with the required details for access.
Cheers,
Daniel
On 09/09/14 12:22, Luis Azedo wrote:
Hello Awesome Kamailio Community,
We are writing on behalf of 2600hz, where we have been using Kamailio
for some time now and are very pleased with our results! So, seems
time to commit something back, dontchya think?
We would like to present to you a new module, to hopefully be included
in master. We call it db_kazoo (although a new name is fine too).
db_kazoo is a general purpose AMQP connector (connects to our
rabbitmq-server). It exposes publish/consume capabilities into
Kamailio. Why is this amazing, you ask? Well even if you didn’t ask,
we will explain…
From a high-level, the purpose of the module might be for things like:
- Integrate to an AMQP application to make real-time routing decisions
(instead of using, say, a SQL database)
- Provide a real-time integration into your program, instead of your
database, so you can overlay additional logic in your preferred
language while also utilizing a message bus
- Utilize messaging to have a distributed messaging layer, such that
machines processing requests/responses/events can go up/down or share
the workload and your Kamailio node will still be happy
With this module, someone can:
1 - publish json payloads to rabbitmq
2 - publish json payloads to rabbitmq and wait for correlated response
message
3 - subscribe to an exchange with a routing key
The module works with a main forked process that does the
communication with rabbitmq for issuing publishes, waiting for replies
and consuming messages. When it consumes a message it defers the
process to a worker process so that it doesn't block this main process.
The worker process issues an event-route where we can act on the
received payload. The name of the event-route is composed by values
extracted from the payload.
Consumed messages have the option of being acknowledge in two ways:
1 - immediately when received
2 - after processing by the worker
One unique feature of our implementation revolves around failover of
the message bus itself. In our design, the module supports multiple
RabbitMQ servers and will fallback from one to the next in a list of
RabbitMQ servers if the connection fails to the current connected
server. When using acknowledge in db_kazoo with clustering in
RabbitMQ, we have simulated and experienced full reconnects while in
the middle of processing pending messages. In this way, when we get
disconnected from one server we proved that, even at high speeds, we
are able to connect to the next in the list and continue interacting
with our application.
We have run a variety of sipp load tests on this module and believe it
is ready for prime time. We monitored memory, response accuracy and
overall stability and it seemed OK. But we would, of course, love for
others to help us find what we have missed, or contribute more
features, or overall just use the work we slaved over for so many
hours. Or just make comments and suggestions!
If nothing else, we hope we’ve provided something useful to the
Kamailio community, as you all have provided useful items to us.
Thanks to everyone for all the work on Kamailio and related products.
Look forward to hearing from you all.
This is our first formal / large contribution to Kamailio so if we’ve
done something wrong process, code or otherwise please let us know!
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 -
http://www.asipto.com
Sep 22-25, Berlin, Germany