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.
Related
I have a use case where MSMQ server is running in our clients infrastructure and we have to receive messages sent by them on the MSMQ queue. I know MSMQ is a windows based system and will work best with windows but is there a way I can just get the messages in Linux ?
Thanks,
Anuj
The typical way to solve it is to bridge to some multi platform messaging product. ActiveMQ, RabbitMQ or whatnot. For that you probably need to write a small bridge service on a Windows server. So that all messages are relayed through "the multi platform broker".
I am aware that the Tibco EMS provides Fault Tolerance in a hot backup configuration on the server side as detailed in the User's Guide, this answer and here.
But on the client side does Tibco EMS provide out of the box solution for fault-tolerant clients?
An example: on the topic Sports.F1.PitStop two clients (server1, server2) register as publishers. The idea being that should something go wrong on server1 (i.e. publisher on server1 goes down), server2 would seamlessly continue to publish on the topic. So the question is, does Tibco EMS provide such client-side fault-tolerance capability?
No.
EMS (or JMS) does not support a client-side fault tolerance feature. The reason is simple : typically, publishers processes don't know each other.
To elaborate:
Topics usually accepts many publishers (more than two).
In a pub/sub scenario, publishers don't know subscribers, and to an extent they don't typically know the other publishers.
Your solution:
My first question regarding your solution: Why can't both servers publish messages at the same time ?
I assume you have a good reason (like messages from server1 and server2 being redundant). In that case, then you will have to have some kind of communication between your "active" and "passive" server.
Possibility 1 : Server2 is connected to a simple service/rmi/other heartbeat mechanism, and can tell if/when Server1 as stopped publishing.
Possibility 2 : Server2 is itself subscribed to the topic, and can tell when messages have stopped.
Last note:
In case you meant shared "subscriptions" (as in, one durable subscription being shared between two servers): the new JMS 2.0 API is supporting this feature. EMS 8 is the only version of EMS supporting JMS 2.0.
I'm not sure if I fully understand your question. EMS is a message broker. It brokers messages. Thats all it does. If you have multiple servers publishing to the same topic, then that is fine for EMS. If your publishers themselves are in a fail-over configuration, so that only one is actively sending and the other takes over when the first one fails, then EMS doesn't care.
Managing the fail-over mechanism from one publisher to the other, that is something you have to develop yourself. EMS doesn't offer anything to support that. You need some kind of mechanism for server2 to know when server1 is down. There are several ways you can do that:
Use a heartbeat mechanism where the active server sends periodical heartbeat messages (possibly across EMS as well) and the passive server listens to them and when they stop, assume server1 is down.
Use an active open connection between server1 and server2 (open a simple tcp port for example and stop it from closing automatically by periodically sending a dummy message), and have an open read on that port. You'll get a connection error the moment server1 goes down and you don't have to wait for timeouts on heartbeats.
Use a third party monitoring tool, such as openview, tivoli or nagios to detect server1 is down and inform server2.
There is a feature on EMS you can use. EMS has system admin topics that you can subscribe to and that log basically anything that goes on internally. You can subscribe to connect and disconnect events to monitor any component connecting to or disconnecting from EMS. If server1 fails, this will be visible as a disconnect event.
heartbeat mecanism:
https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-33918
For example:
client_heartbeat_server=10
client_timeout_server_connection=35
server_heartbeat_client=10
server_timeout_client_connection=35
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.
When deploying a web application running on a traditional web server, you usually restart the web server after the code updates. Due to the nature of HTTP, this is not a problem for the users. On the next request they will get the latest updates.
But what about a WebSocket server? If I restart or kill the old process all connected users will get disconnected. So my question is, what kind of strategy have you used to deploy a WebSocket server smoothly?
You're right, every connected user will be disconnected if the server restarts.
I think the less bad solution is to tell to the client to reconnect in the onClose method of the client.
WebSockets is just a transport mechanism. Libraries like socket.io exist to build on that transport -- and provide heartbeats, browser fallbacks, graceful reconnects and handle other edge-cases found in real-time applications.
In our WebSocket-enabled application, socket.io is central to ensuring our continuous deployment setup doesn't break users' active socket connections.
If clients are connected directly to sever that does all sockets networking and application logic, then yes - they will be disconnected, due to TCP layer that holds connection.
If you have gateway that clients will be connecting to, and that gateway application is running on another server, but will communicate and forward messages to logical server, then logical server will send them back and gateway will send back to client responses. With such infrastructure, you have to implement stacking of packets on gateway until it will re-establish connection with logical server. Logical server might notify gateway server before restart. That way client will have connection, it will just wont receive any responses.
Or you can implement on client side reconnection.
With HTTP, every time you navigate away, browser actually is creating socket connection to server, transmits all data and closes it (in most cases). And then all website data is local, until you navigate away.
With WebSockets it is continuous connection, and there is no reconnection on requests. Thats why you have to implement simple mechanics when WebSockets getting closing event, you will try to reconnect periodically on client side.
It is more based on your specific needs.
From here.
While electronic mail servers and other mail transfer agents use SMTP to send and receive mail messages, user-level client mail applications typically only use SMTP for sending messages to a mail server for relaying. For receiving messages, client applications usually use either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP) or a proprietary system (such as Microsoft Exchange or Lotus Notes/Domino) to access their mail box accounts on a mail server.
Why is that?
On that same page it talks about it.
SMTP vs mail retrieval
SMTP is a
delivery protocol only. It cannot pull
messages from a remote server on
demand. Other protocols, such as the
Post Office Protocol (POP) and the
Internet Message Access Protocol
(IMAP) are specifically designed for
retrieving messages and managing mail
boxes. However, SMTP has a feature to
initiate mail queue processing on a
remote server so that the requesting
system may receive any messages
destined for it (cf. Remote Message
Queue Starting). POP and IMAP are
preferred protocols when a user's
personal computer is only
intermittently powered up, or Internet
connectivity is only transient and
hosts cannot receive message during
off-line periods.
SMTP was designed for use with "always on" servers; most people do not leave their mail client running 24x7 and able to receive email at all times. More recently it became possible to use ETRN to instruct a remote server to try to deliver anything queued up for a client, but this is still not widely supported and in general doesn't work as well as client-side "pull" (or IMAP's fake-push IDLE extension).
There's an additional issue in that most servers send warnings to the original sender when delivery to the next server fails; this is a good thing for intra-server transfers but a bad thing for intermittently connected clients.