I've created a console application that listens to a queue using WCF in the past and have no problems with that implementation.
My question:
If, instead of listening to the queue on a console application, I listen to a queue through my website, when would the message be picked up? Would it be instant, as is the case with the console app? Would the message only be received when someone requests a page on the site?
Regards.
A website is not a good host container for a MSMQ client. The reason is the app pool unloads during time of low traffic.
So effectively you are correct in that you will not consume message until the app pool is loaded.
However, that does not prevent others from sending you messages, as the queue receives the messages regardless of whether your client is loaded or not. These would then be stored until the client came back to consume them (providing the queues are durable).
A windows service would be a much more appropriate container.
Related
If I have an app (let's Express.js app) with a web socket (socket.io) and I want to send message to a client from a different server app, what is the best way to go about that.
Let's assume that both apps are on a public cloud and running on separate containers or VMs. What's the best way to ensure that the message is sent to the right web socket app instance that holds the connection to the client?
You can use redis to ensure that client will get the message no matter which instance of app is sending the message.
But if your other app is a completely different app and does not start a socket server, You can still use socket.io emitter (along with redis adaptor) to send messages to clients without creating another socket server.
I'm working on a project to develop a real time mobile messaging application that needs to have advanced message filtering based on message content and user's balance, meaning that if the user has ran out of balance or if he's sending content that violates the policy the messages have to be blocked.
For this reason I need to implement some load balancing solution that scans published messages and could also determine if the message should be blocked based on the rules above, hence I can't implement a basic proxy as I need special rules applied on each message.
The difficult part:
Mobile app needs to receive subscription messages (connection acknowledgement too) without passing through the load balancer preferably (see my next point).
The problem is that the only way I could forward subscription messages to the mobile app would be by handling connections and subscriptions in the load balancer which is disastrous. I need the connections to be transparent and the load balancer stateless.
How can I accomplish this? (if it's of any help my current design involves Java component with spring boot for load balancing and VerneMQ as the message broker)
Try
Mobile App -- > MQTT Broker -- > Message Scan / Block Algorithm -- > MQTT Broker -- > Subscriber.
Your mobile app should have the intelligence to stop messages when the app runs out of balance after the first message.
So the MQTT Broker should not send the message to its subscriber directly at its layer. It should send out messsages that were received after processing.
Not sure anyone has a ready made solution for this flow. But doable.
I noticed strange problem in my web app.
Web app is hosted on AWS, is made in SpringBoot framework and its main responsibility is consuming messages from MQ. Messages are consumed one by one - there is no concurrency.
I am using MQQueueConnectionFactory class to prepare my connection,
I properly set parameters like:
host
port
queue manager
channel
int property
client reconnect options
and all ssl required parameters.
All seems to work well all the time until something happen and messages from MQ are not consumed. I can see messages which are waiting for being consumed, but web app does not consume it. After web app is restarted all work fine. I think it can be problem with connection which seems to be broken after some time (several days). I set reconnect option to connection factory class and for now I do not know what to do else to fix it.
Have you ever met similar problem? Do you have any clues?
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
I'm currently using Socket.IO with redis store.
And I'm using Room feature with it.
So I'm totally okay with Room join (subscribe)
and Leave (unsubscribe) with Socket.IO.
I just see this page
http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/
And I have found that some people are using Socket.IO with rabbitMQ.
Why using Socket.IO alone is not good enough?
Is there any good reason to use Socket.IO with rabbitMQ?
SocketIO is a browser --> server transport mechanism whereas RabbitMQ is a server --> server message bus.
The two can be implemented together to create a very responsive system in scenarios where a user journey consists of a message starting life on a browser and ending up in, say, some persistence layer (such as a database).
A message would be transported to the web server via socketIO and then, instead of the web server being responsible for persisting the message, it would drop it on a Rabbit queue and leave some other process responsible for persisting it. This way, the web server is free to return to its web serving responsibilities and, crucially, lessening its load.
Take a look at SockJS http://sockjs.org .
It's made by the RabbitMQ team
It's simpler than Socket.io
There's an erlang server for SockJS
Apart from that, there is an experimental project within RabbitMQ team that intends to provide a SockJS plugin for RabbitMQ.
I just used rabbitMQ with socket.io for a totally different reason than in the accepted answer. It wasn't that relevant in 2012, that's why I'm updating here.
I'm using a docker swarm deployment of a chat application with scalability and high availability. I have three replicas of the chat application (which uses socket.io) running in the cluster. The swarm cluster automatically load-balances the incoming requests and at any given time a client might get connected to any of the three replicas of the application.
With this scenario, it gets really necessary to sync the WebSocket responses in the replicas of the application because two clients connected to two different instances of the application wouldn't get each other's messages because they've been connected to different WebSockets.
This is where rabbitMQ intervenes. It syncs all the instances of the application and whenever a message is pushed from a WebSocket on a replica, it gets pushed by all replicas.
Complete details of the project have been given here. This is a potential use case of socket.io and rabbitMQ use in conjunction. This goes for any application using socket.io in a distributed environment with high availability and scalability.