I am looking for a light weight and robust AMQP consumer for sending emails using sendmail. Dose anything like this exists or do I have to write something on my own?
You will likely have to write your own. The closest thing I've seen is a [plugin to receive SMTP in RabbitMQ which is definitely not what you want.
A general solution for this can become rather complex managing idempotency of the messages. In previous solutions to this problem I passed a unique ID in the message and use a persistent store to handle deduplication. After successfully handing off the email the ID is written. Depending on how sure you want to be about ensuring hand-off / preventing duplication you can add more of a lock.
MailerQ could be similar to what you are looking for. However, it uses it's own SMTP server, and not sendmail.
I'm also looking for some consumer application that can receive RabbitMQ messages and send them as emails. However, I need it to use an external SMTP server, so MailerQ is not right for me.
Related
What are the best practices for sending system message/s to group/ user, while using XMPP protocol? All the users at at the group should receive the message.
How can I achieve it?
Possible solutions that might be useful:
The announce - I have encountered with the announce and more
specifically this module.
Publish-Subscribe http://www.xmpp.org/extensions/xep-0060.html
There is always the
option of creating an admin user that will send messages.
Thanks in advance.
The best approach depends on your constrain and especially if you control the client. For example, if you use a client you did not develop, it may not render the pubsub messages fine.
The second thing to consider if how are the group defined. Are users registering for alerts ? In that case in seems to match the pubsub case. Otherwise, if groups are not too large, you may use an admin user to send to the list of user you want. You can even send a single message to multiple users using XEP-0033: Extended Stanza Addressing (Sometimes called "multicast").
mod_announce can only target all users or all online users, so it does not seem to match your need in terms of "groups".
I explained most of the option in a talk (video and slides): https://blog.process-one.net/implementing-state-of-the-art-one-to-many-chat-services-with-ejabberd-ejabberd-workshop-1/
It is broader as it not only cover broadcast but also groupchat, but it should help clarifying your choice.
I'm willing to use ejabberd / mongooseIm in a microservice network. XMPP should be our chat protocol aside from a REST API network. I want to send messages incoming at the xmpp server downstream to worker services. Has anybody done this or could lead me into the right direction?
My first thoughts are using RabbitMQ for sending the new incoming messages to the workers.
There are basically two choices to giving your workers access to the messages routed by ejabberd / MongooseIM. I'll focus on MongooseIM, since I know it better (DISCLAIMER: I'm in the dev team).
The first is to scan the message archive in an async / polling fashion. The Message Archive Management describes XMPP level protocol for accessing it, but for your use case the important part is message persistence - so just making sure the relevant module (mod_mam) is enabled in server config and the messages will hit the database. The databases supported for MAM are PostgreSQL and Riak, though there was also some work on a Cassandra backend (YMMV). This doesn't require tinkering with the server / in Erlang for as long as there's a DB driver for your language of choice available. Since PR#657 it's possible to store the messages in raw XML or even some custom format if you're willing to write the serialization module.
The second option is to use the server mechanism of hooks and handlers (also available in ejabberd), which can trigger a server action on events like "user sent a message", "user logged in", "user logged out", ... This, however, requires a server side extension written in Erlang. In the simplest case the extension could forward any interesting event (with message content and metadata) via AMQP or just call some external HTTP/REST API - that way the real work is carried out by the workers giving you the freedom with regard to implementation language. This options also doesn't require to enable mod_mam or set up a database for message persistency (which you could still have with a persistent message queue...).
In general, the idea is perfectly feasible.
Generally, the most common XMPP extension use to build messaging systems for machines-to-machines, internet of things, microservices, etc is PubSub, as defined in XEP-0060.
This is a module you can enable in ejabberd. It is API based, so you can even customize the behaviour of that module to your application specific.
Pubsub basically allows to decouple senders and receivers and is especially designed for that use case.
I'm using SmackAPI to transmit custom IQ Packets between two Java applications. The XMPP Server is a local OpenFire installation. In principle the sending and receiving of this packets works fine. But now i want to send to multiple recipients. For messages this can be done very easily by using the MultipleRecipientManager class. But I have no idea how to send custom IQs to multiple recipients without sending them multiple times. I tried to just use the MultipleRecipientManager like with normal messages, but this is not working. Adding an extension (MultipleAddresses) to the custom IQ object does not work and hardcoding the addresses in the getChildElementXML method also does not work.
I always get an error from the xmpp server. It tells, that the service is unavailable. I think the problem is, that the server does not know my custom IQ, but how can I change this?
Extended Stanza Addressing is supported by my Openfire installation. But it seems like it is only working for normal messages.
I hope someone knows how to solve that.
Best regards
Stefan
For messages this can be done very easily by using the
MultipleRecipientManager class. But I have no idea how to send custom
IQs to multiple recipients without sending them multiple times.
There is no way to transfer the approach used by MultipleRecipientManager to IQs. You have to send them multiple times.
Your question makes me wonder if you haven't a design flaw in your implementation. IQ stanzas of type 'get' or 'set' need to be acknowledged by the receiver. That is also the reason why XEP-33 was specified to only work with messages. In theory you could use the 'from' attribute to track that every receiver has ack'd an IQ with an certain ID. But I guess this isn't done because it adds to much complexity to the protocol for little gain.
Anyway, it appears that you don't care for for the IQ results, so why not use messages instead?
i would like to take messages from amazon sqs in the same order in which it is inserted into sqs ( first in first out model).
Is their any way to implement it??
I am using zend php for programing.
Unordered message delivery is inherent in the design of SQS. You could try to work around it by numbering the messages and storing the out-of-order messages locally until the missing messages arrive, but its probably not worth the hassle.
SQS is really a bit of an odd duck, it does what it says, but what it does isn't what most people are looking for in a message bus. I really wish Amazon would offer and additional queuing solution more like RabbitMQ. SQS is really only suited for distributing tasks that aren't even remotely coupled, and where things like order and latency aren't important. For instance it would be great for sending completed orders to a shipping center, or perhaps scheduling print jobs.
Their own documentation shows it being used to schedule thumbnail creation, but when I recently used it for this exact purpose I quickly discovered that my users weren't going to be impressed with the latency: which at times is 30-50 seconds.
You can still run RabbitMQ on EC2 nodes, and while not as scalable as SQS it does cluster and should take you pretty far.
You could try IronMQ. It is hosted like SQS, has guaranteed first in first out ordering, no eventual consistency delays, is uber scalable and you can be up and running in minutes.
Here's a PHP library for it: https://github.com/iron-io/iron_mq_php
Disclaimer: I work for Iron.io
The SQS documentation answers this for you (bold is my emphasis to directly answer your question):
Amazon SQS makes a best effort to preserve order in messages, but due
to the distributed nature of the queue, we cannot guarantee you will
receive messages in the exact order you sent them. If your system
requires that order be preserved, we recommend you place sequencing
information in each message so you can reorder the messages upon
receipt.
I have tried to implement the FIFO fashion for receiving the messages in the same order they were sent
For this you can use message sequence no which it sent every time with message and validate at the receiver end
By Using this way you can get desired output in FIFO order
(newbie alert)
I need to program a multiparty communication service for a course project, and I am considering XMPP for it.
The service needs following messaging semantics:
1) server will provide a method of registering and unregistering an address such as somenode#myservice.com/SomeResource. (for now I will do it manually).
2) server will provide a method of forwarding incoming messages from, say, somenode#myservice.com/SomeResource to someothernode#myservice.com/someOtherResource, assuming that the latter is registered, and a method for removing this forwarding. (for now I will do it manually).
3) anonymous clients can send messages to, say, somenode#myservice.com/someresource (one way traffic only). If there is any forwarding setup, the message will be forwarded. Finally if the address is somenode#myservice.com/someresource is registered, the message will be stored for later delivery (or immediate if a retrieving client is online - see below). If no forwarding and unregistered, message will be silently dropped.
4) clients can connect and retrieve messages from a registered address. Exact method of authenticating clients (e.g., passwords?) is yet to be determined.
Eventually, I want to add support for clients to connect from a web browser so they can register/unregister and set/remove forwarding themselves.
Thus, the server will have to do some non-standard switching. Will I need to implement an XMPP server for this? I guess some (or all?) of this can also be done using a XMPP client bot
You might investigate whether Pub/Sub is a better fit for your problem than custom messaging semantics. If so, you may find an implementation of it in your existing XMPP server.
You could probably get away with using a message queue like ActiveMQ for the communication and Apache Camel for the routing/forwarding/processing.