My message-queue is managed by IBM WebSphere MQ and I would like to be able to listen for new enqueued messages using a WCF service.
Each new message should trigger a call to my service with the new message as a parameter.
Do you know any way about how to create such a service and host it?
If you are using WebSphere MQ v701 or above, then you can use the WebSphere MQ Custom channel for WCF. Using the custom channel you can build and host services. You can find more details and samples here
WMQ WCF based service can be hosted as a Windows service or a standalone application. It does not yet have capability to be hosted in an IIS or Windows Application Fabric/WAS.
Related
I am looking in for the best way to implement the RabbitMQ consumer by using .Net Client which should be run as windows service.
I referred the RabbitMQ documentation and found the way to consume messages by using .Net client (https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html).
My current scenario is like, RabbitMQ is installed in AWS VM machine. I have to install dotnet client consumer service resides in On-premise network which should consume messages.
Which one is the best way, to always listen the Queue (AMQP protocol) or HTTP API which should get messages on demand (https://pulse.mozilla.org/api/).
Please advise.
Thanks,
Vinoth
I believe the answer is "neither." You should have your message queue as a back-end service behind the firewall, and expose your application functionality through a set of carefully-specified web services. The web services, which are exposed through the firewall but can communicate to services behind the firewall, would produce messages that would be transmitted to the server. Any services needing to produce or consume messages would need to do so via the web services, which would perform safety/security checking prior to forwarding the request on to the AMQP server.
If you need to expose AMQP directly to clients (i.e. that is the purpose of your app), then the recommendation is to do so via STOMP. I think a valid use case for exposing AMQP directly over the internet would be a rare thing to come across. The security implications of doing so would be immense.
I'm trying to figure out what is the best solution to work with rabbitmq cluster via wcf.
Current setup:
2 IIS web servers (act as message produces and post messages to queue via amqp wcf client).
2 servers with rabbitmq broker (clustered with mirrored queue, rabbit1 and rabbit2)
Windows service ( worker) with hosted amqp wcf service that listens to incoming messages.
Web role posts messages to rabbit1 node and worker listens to rabbit1 node too. If rabbit1 node fails system(both web and worker) should switch to rabbit2. And that's the question, how to implement this in more elegant way rather than handling connection failures in application code.
First and the only approach I see now is to use wcf4 routing backup endpoints feature. This way solves problem on client side(web role) only but doesn't solve problem on wcf service side(worker role).
One way is to create a wrapper around your service host, used for storing a list of connection strings (which can come from config).
Add a handler to the service faulted event, where you can close and reopen the host with a different connection string.
I have a WCF Service hosted on IIS 7 that runs successfully for a period of time, then fails to communicate to other network locations ( I suspect there are no TCP ports available to connect to the outside world )
Background of application:
My system transcodes large media files ( which takes time). I have a centrally hosted WCF service which is is located on server A - which will be referred to as 'Central WCF Service'. I then have many client services which do the actual transcoding of the media files on different servers: B,C,D,E,F and so on - which will be referred to as 'Client Processor services'. The Central WCF Service manages which Client Processor Service the 'Transcode Jobs' get sent to be processed . Each of these Client Processor Services is a self hosted WCF service, they basically do the long running process, and get polled by the Central WCF Service checking job progress percentage. The Central WCF service therefore opens up a lot of connections to these clients to poll them for their job progresss, polling occurs roughly once every 2-3 seconds to each of the clients.
The Central WCF service stores a string list of the addresses for the Client Processor services. The code which Is used to poll each client is descrbied below ( stripped down version ):
public ClientProcessorClient getClientByaddress(string address)
{
Binding bidning = new NetTcpBinding(SecurityMode.None);
return new ClientProcessorClient(bidning, new EndpointAddress(address));
}
public void pollJobs()
{
foreach (string clientAddress in clients)
{
ClientProcessorClient client = getClientByaddress(clientAddress);
int progress = client.GetProgress();
client.Close();
// Do stuff with progress
}
}
What happens when it breaks:
I can submit many transcode jobs to the Central WCF Service and it submits jobs to the clients successfully updating progress etc. After around an hour of processing the server that the Central WCF service is hosted on stops working properly. Errors are thrown by the Central WCF Service Insufficient winsock resources available to complete socket connection initiation. when trying to contact the Client WCF services. The Client WCF services are all pingable from a WCF Test Client running on my local machine. Also I have noticed that when in this state the server cannot view network file resources - I have logged in remotely and tried to locate a network attached storage folder, it fails to connect. I CAN however make calls TO that server e.g. I can open a WCF Test Client and connect to the Central WCF Service and call it's ping methods. Communications are allowed IN but not OUT from the server.
Few points of interest:
In the faulted state the connections TO the server can be made, but not FROM the server.
Each of my services ( Central WCF service and Client Processor Service ) are singleton instances.
The Central WCF Service is hosted in IIS 7 and application pool Recycling is disabled
Unfortunately named pipe is not an option ( the clients and servers are on different machines )
My thoughts/Questions
All signs point towards the server running out of TCP sockets. Am I setting up the WCF ClientProcessorClient's properly? Am I disposing of them properly? Do I need to wrap them in a using statement? Does anybody know how I can debug/diagnose where the problem occurs?
Thanks
For good or ill, Microsoft decided to implement the WCF service proxy logic (either ClientBase or directly from ChannelFactory) to allow exceptions to be thrown in the Close() method. I believe all the Dispose() method does is call Close() but I have never tried to look at the source code. If a proxy is in a faulted state, Abort() must be called to release resources (such as TCP sessions).
The implication is the WCF service proxy does not release resources until a call to either Close() or Abort() completes successfully. Take a look at this blog post for one option to properly closing the proxy instance.
I have a WPF app that uses WCF (duplex netMsmqBinding) to talk to a self-hosted service app in our domain.
I'm now trying to move this WPF app to the big wide world out there, to talk to the WCF service over the internet (well, make them talk to each other).
I've installed MSMQ and created the services on both, and checked queue and firewall permissions. Based on the reading I've found, what I needed to do then is:
1) Enable MSMQ's HTTP addon.
2) specify the binding's useActiveDirectory=false and queueTransferProtocol="Srmp" to ensure that it uses DIRECT to find the private queue.
However I did that and the WPF app receives the error
An error occurred while opening the queue:Unrecognized error
-1072824215 (0xc00e0069). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that
the queue is available to open with the required access mode and
authorization.
Which translates to MQ_ERROR_REMOTE_MACHINE_NOT_AVAILABLE.
I can browse to the remote server ok, and the rest services work fine, so I must be missing something with HTTP or the fact that it's self hosting. Any ideas?
MSMQ over HTTP is a push technology (client -> web server).
You cannot open a remote queue and pull messages from it.
I have a WCF service with netMsmqBinding. My client can send messages to my queue, and when the service is running it retrieves messages from the queue as expected. If the service is not running, messages received are queued until the service starts.
My problem is that the service does not start when a message hits the queue. The service is hosted in IIS, and so it is not instantiated until IIS receives a request. If I browse to the service then it processes the messages in the queue, but obviously this is not my desired method of processing the queue!
I expect that I need to change the service implementation, or change the IIS setup, but I do not know where or what to change.
UPDATE
Does anyone actually use MSMQ over WCF? I had this working for a short time - I enabled the binding on a different website on the same server, bizarrely - but now it has somehow stopped working again.
The only problem I am having is with the Activation of the service when there is a message in the queue. At present the queue only processes when the service is instantiated, e.g. when I browse the the .svc file. I have the net.msmq protocol enabled on the application, and I have the net.msmq binding enabled on the site... is there anything else I need to do?
You explicitly need to configure IIS for non HTTP activation. I don't know all the details of the top of my head but basically you need to use appcmd to configure and enable the net.msmq binding activation.
Check this blogpost or this screencast should give you all the details.
This might save somebody the hours it took me:
http://msdn.microsoft.com/en-us/library/ms731053.aspx
I believe that my problems using MSMQ binding over WCF were mainly around IIS.
I had no end of problems using Windows XP / Server 2003 with IIS 6.
Using Windows 7 or Server 2008 with IIS 7.5 everything works well.
An even better suggestion is to run MSMQ as a managed service / Windows Service or a stand-alone application rather than under IIS.