Per MUC channel bot managed by ejabberd - service

I would like to run one service process per MUC channel on an ejabberd server. Ideally I would like ejabberd to start / monitor that process.
That is, when a new MUC gets opened ejabberd should start the bot process and tell it the channel name through commandline options. The process will then connect to that MUC on its own and do its thing. in case it crashes, ejabberd should notice and try to restart it. In case the MUC gets closed, so should the bot process. Is such functionality available with ejabberd?

I am not aware of anything like that implemented.

Related

Get all the running instances using nagios

I have a certain number of hosts running different servers. All of them have nagios plugin installed. I wanted to write a script that would tell me daily if all the instances are up and running.
I tried opsview, but due to certain restrictions, I couldn't go ahead with it. It was then that I decided to use the nagios plugin directly. I thought about NRPE but it would be used to run a plugin remotely (provided you must know the address of the host), but in my case, I want to know if someone added a new server overnight, or some server failed or what all servers are running.
Nagios doesn't do discovery. You configure it with a list of machines and services to check.
Assuming we're talking about cloud servers, AWS can send you a message when a new server is added. See the doc The message can be SNS or SQS. These notifications could be read to rebuild your nagios configuration to match the auto-scale group.

MassTransit MSMQ remote queues not reachable

We've developed a MassTransit based demo which is working well as long as all processes run on the same server.
However, as sonn as my receiver wants to subscribe himself at another machine it hangs for a while and afterwards we receive the following exception:
"System.InvalidOperationException: Timeout waiting for subscription service to respond."
Checked already: Firewall rules for MSMQ (inbound and outbound), network, etc.
What could have gone wrong?
Subscription queues on the other machine are private? Is this a problem?
Do we have to change the address format in some special way? msmq://computerName/queueName not ok for remote connections?
Looks like we have forgotten some tiny thing, as nobody else had this problem before...
The most likely thing is MT assumes somethings about remote queues - that they are transactional. Local queues can be queried to discover that, but remote queues you cannot. I would add ?tx=false to the end of your remote queue URI if you aren't using transactional queues for the subscription service.
Next, double check the outgoing queues on the local machine. Are the message stuck there or did they disappear? If you are using transactional queues, can the machines enroll in a DTC transaction together?
Answering your question, all queues are private. This is not a problem, they are still remotely addressable.
I hope this helps get you further. After that, I would consider joining the mailing list and posting your questions there: https://groups.google.com/forum/?fromgroups#!forum/masstransit-discuss
For reference: the problem has been a wrong URL in the receiver queue, the receiver queue always resides on the local system of course. Sorry for any inconvenience.

What is the syntax for sending Jabber/Gtalk notifications in Monit

I noticed in the release log (http://mmonit.com/wiki/MMonit/Release2-1) Monit supports Jabber/GTalk messages but I can't find the proper syntax in any of the documentation. I'm trying to send out an alert via gTalk when a host goes down.
M/Monit (the Monit management server) can send XMPP messages. The monit daemon can only send email on its own.

What Happens To MSMQ When Network Connection Lost

If I am using MSMQ over the web, what happens if the network connection is lost between client and server?
So can you still add messages to the Queue, and if so where are they stored? In the client app, or in the clients OS etc?
For instance if I have a windows service which is adding items to a queue in a different country. What if the network connection is lost, and the windows service is restarted. Do the messages get lost forever?
The other part of the question relates to the route that a message takes, is it sent directly to the receiving queue, or is it written into a queue on the client side? Does that require MSMQ to be installed on the sending server, and how about licensing for that?
Is there any good documentation to explain the required setup?
Update: Regarding your follow up question. Yes you have to install msmq on the sending server. There aren't any licensing cost, because MSMQ is part of windows and not a separate software (just like the IIS). Here is documentation on "Setting Up a Message Queue" on windwos 2003.
Before Update: Outgoing message are stored in the outgoing queue of the sending server. They are not lost if the sending service is restarted. They will wait in the outgoing queues ( which can be inspected with the msmq manager ) for I don't know how long.
if the msmq service or the sending server are restarted. Then "express" messages will be lost. express or recoverable are properties of non-transcriptional messages.

MSMQ - how to Communicate between two application

I started looking into MSMQ very recently so i have basic doubts . If two application needs to communicate lets say server and client I think both will share the same MQ address and when the client update then the Server will be having the MSMQ watcher which will listen to the message pick and use it. So according to me there are three component we need
Client - which knows the Queue location
Queue watcher - which watches the queue
service -- to which queue watcher will send the message to
Tom Hollander wrote an excellent series of three articles on WCF and MSMQ. They helped me alot when I had to build an application to communicate via MSMQ. There is a third article but Stack Overflow won't let me post since I'm a new user. You can find the link to it from the 2nd article.
MSMQ, WCF and IIS: Getting them to play nice (Part 1)
MSMQ, WCF and IIS: Getting them to play nice (Part 2)