I have one MSMQ-WCF service that is creating a queue and maintains the MSMQ queue service.
Also, I have another WCF Services hosted in WAS, working like a Listener.
As soon as a message arrives in the MSMQ Queue, it should be automatically picked from the queue and the message should be read.
I just wanted to use it MSMQ Listener adapter. Is there any other way to do this? Please let me know.
It's much simpler to host the queue listener in a windows service. This way there is no need to involve WAS and all the complicated setup that can involve.
Related
I'm using C# for my project and I've successfully set up the RabbitMQ Message Queue with a windows service that publishes to the queue. I've also created another windows service for a consumer on the same machine as the RabbitMQ message queue. Is there a way to have the consumers running on a different machine than the message queue? Everything works great locally right now, but I envision having separate machines for the producers, message queue, and consumers. I'm not sure if there's a built-in way to do this or if I need to employ something else to communicate between the message queue and my consumers. Thanks!
For the consumer | publisher there will be a connection string that will most likely point to localhost with a user/pass of guest. You will first need to setup a new user in RabbitMQ that can access the vhost you need access and then update the connection.
This is rather a stupid question. But I couldn't find a good post regarding this.I want to create a queue in Outgoing queue in MSMQ.
I have a task to get all the Outgoing queues in the machine and clear the messages if it matches to a criteria.
Can anybody give an idea how to create an Outgoing queue in Windows server 2008 machine.
You don't "create" an outgoing queue.
When you send a message to a queue the MSMQ sub-system first writes the message to a local, temporary, outgoing queue before transmitting the message to the destination queue. The lifespan of the temporary outgoing queue is controlled by the MSMQ sub-system and not the developer.
This is because MSMQ uses a store and forward model to transmit messages around.
John Breakwell talks about this here.
However, you can address the outgoing queues in the same way you would address the remote queue which you are sending to, but setting a flag called MQ_ADMIN_ACCESS.
This technique is described here.
I am fixing a .net app written on top of nServiceBus and have a few questions:
The app is configured AsA_Publisher and when it starts it waits for incoming
connections on a socket, do you know why it might have been implemented like so?
Why sockets? This socket is created during the Run method of a class which implements class IWantToRunAtStartup.
Once a message arrives, the message is written to a queue (Q1). The message
is then read from the queue(Q1). The format of the message is changed and then
inserted into yet another queue (Q2). The message is then read from the queue
(Q2) and sent to another application by calling a web service. The whole idea is
to change the message format and send it off to the final destination. If
nServiceBus is built on top of MSMQ, then why is the application creating more
queues and managing them?
I see absolutely nothing about Publish or Subscribe anywhere in the project. I guess it is relying on the socket to receive messages and if so then it is not really taking advantage of nServiceBus's queuing facility? Or am I lost...
If queues are needed and if I was to build this I will have one app writing to
the queue (Q1), another app reading from the queue (Q1) and changing the format
and inserting to another queue (Q2) and finally a third app reading from the
(Q2) and sending it off to the web service. What do you think?
Thanks,
I see nothing wrong with opening a socket in Run in an IWantToRunAtStartup. It must somehow be required that the service can be reached through some custom protocol implemented on top of sockets.
Processing the incoming socket messages by immediately bus.Sending a message is also the way to go - the greatest degree of reliability is achieved by immediately doing the safest thing possible: sending a durable message.
Performing the message translation in a handler and bus.Sending the result in another message is ALSO the way to go - especially if the translation is somehow expensive and it makes sense to be able to pick up processing at this point if e.g. the web service call fails.
Making a web service call in a message handler is also be the way to go - especially if the web service call is idempotent, so it doesn't break anything if the message ever gets retried.
In other words, it sounds like the service correctly bridges a socket-based interface to a web service-based interface.
It sounds weird, however, that the service employs multiple queues to achieve this. With NServiceBus it would be entirely sufficient with one single queue: the service's input queue.
I have a winforms client application that sends messages to an asp.net web service, I need to be able to queue these messages on the client and then then send them in order, waiting for a response from the webservice before sending the next message.
I did look at some examples of queueing using WCF but they seemed to have the queue on the server and not the client.
Any advice abotu what technology to use and on how to implement a solution would be very much appreciated.
Why wait for the response of the server before sending the next message? there is no good reason to do that. Just mark the messages with a sequence number and process them in order at the server.
MSMQ has a queue both on the client and the server and moves the message when a connection is available.
There's also good ol' MSMQ, but that queues things on the server as well.
You could use middleware for the queue (MSMQ etc).
An alternative would be a thread-safe producer/consumer queue at the client. Your "main" code just adds to the queue (ConcurrentQueue in 4.0 might work nicely here, although even in 4.0 I tend to use a utility queue I wrote a while ago instead); and you have a dedicated worker thread that dequeues messages, does the WCF work, and processes the response.
If you need reliable delivery, why not use AMQP with a message broker like RabbitMQ?
I am creating a WCF service (CALLER) for Azure. The service(CALLER) calls async methods of another third party service(EXTN). The third party service calls the callback methods of another WCF service (LISTNER) hosted by me on Azure. CALLER enter the service details in the databsae with status = PENDING.
In the callback service (LISTNER) I am updating the status of the request as COMPLETED/FAILED in the database.
But I want the CALLER should be notified when status is updated in the SQL Azure db.
I am thinking of creating a worker thread which will poll the database periodically to check the status update and notify the CALLER about this.
Is there any other better / efficient alternative to this approach?
The features you're looking for are implemented in the AppFabric service bus.
Not really. There is another way (not sure it works on azure) by using a the integrated SQL message queueing (queue on updates via trigger), and your thread could continously poll then (there is a way to have a the read WAIT for an etnry in teh queue, so you issue one and it waits), but besides that...
...no, not from the database level.
I have a similar application and I handle it by a ntification trigger OUTSIDE The database (i.e. notifications are sent from the business logic that values change).
Another option is to use Queues and have the caller poll for notification messages from the listener. The Service Bus can be used, by having the Caller subscribe to event notifications sent from the Listener. In your scenario though it doesn't provide much more than the Queues do - if you are behind the firewall, the Service Bus uses polling as well.
Queues are probably the most efficient way to send notifications - that's why they were created in the first place. The Service Bus is used to create semi-permanent connections between different services by providing a lot more features than simple message passing. That makes it a bit less flexible, requires a bit more programming. Its billing model (charge per SB connection) reflect this too. You are not expected to use a lot of SB connections.