Does anyone know how to test a WCF TCP endpoint using JMeter?
I'm trying to set up a load test using the TCP Sampler, but when I add the net.tcp://myserver/myservice.svc to the Target Server input box I receive a 500 server error in response: java.net.UnknownHostException: net.tcp://myserver/myservice.svc
The TCP endpoint is working, I've tested it locally using visual studio, but having no luck with JMeter.
Does anyone have any replication steps or example links to help set up a WCF TCP test with JMeter.
I have found nothing on the internets to help with this.
Thanks.
A WCF TCP endpoint uses NetTcpBinding. Even if this binding uses many standards, it's intendended only for WCF-to-WCF communication. It's maybe one of the less interoperable WCF binding.
Please note that accessing the svc or wsdl is totally different from invoking the service.
Try to use another binding for your service (like BasicHttpBinding), or eventually try Visual Studio Load Testing.
You may be making a mistake in server name, you must only put:
myserver
Not net.tcp://myserver/myservice.svc
Related
i'm writing a server side application and a windows service which need to be installed on a remote host
the service returns CPU usage to the serverside application - this is NOT the problem
the serverside application deploys the service on the remote host. - also, not the problem
THE PROBLEM:
but how do i setup a socket connection between the two, when i dont want to hardcode the ip address? (for scalability) - do i need to use multicast or is there some devious way of doing this? is there another solution than using sockets? -
i'm new to writing Windows Services.
I need help figuring out how to communicate between the server and the service without hardcoding IP-addr.
thank you in advance.
MY SOLUTION:
I created a windows service, that reads a xml file with the IP and port of the Server application. so when i deploy my client application, i also create a xml file with the network information.
Regards Alex
A lot of communication platforms now use network discovery; there's an article on codeproject that goes into detail about using network discovery.
The problem was, I did not know what machine name the server was running on, in fact I wanted this to be flexible, and selectable by the user.
Seems relevant to http://www.codeproject.com/Articles/16113/Retreiving-a-list-of-network-computer-names-using
Have you thought of using WCF?
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Regarding multicast, you can have a WCF server multicast announce it's availability on a network; see http://msdn.microsoft.com/en-us/library/dd456782.aspx
another solution could be to create the service as a console application with arguments (endpoint ip address) and then just deploy it with the arguments on the remote host
Someone once told me that in WCF if you use a net.tcp binding but connect to a service that is actually on the localhost it will actually use a net.pipe binding underneath. I'm not sure if the address of the service needs to be localhost, the local IP, etc.
Is this true? Has anyone tested this? Is there any overhead?
Will using net.tcp inter-process open a socket back to the local machine?
I'm pretty sure it doesn't do that. That would be extremely confusing when things don't work the way you expect them to.
Simple story,
I made a server using WCF, now I want to move the server to a different location. When moved client applications needs to be reconfigure the service they are listening because the ip is not the same. Can you automate this, when the server is moved all applications listening to it will autodetect the new location and address of the server.
You need to use WCF 4 and auto discovery feature. Here is a nice link that give you the first steps
Use WCF 4 Discovery.
http://msdn.microsoft.com/en-us/library/dd456782.aspx
One of the services works fine but the other always throws a Socket Timeout 'forcibly closed' error.
I have portSharingEnabled='true' on both services and the netTcp Port Sharing windows service switched on.
I've done a lot of research on this but am unable to find the cause, any suggestions?
It's not an option to change the port either due to legacy system setup.
Each netTcp Binding looks liks this:
8033:*
Is that right or is the * the issue here? I've run out of ideas as you can tell.
Last point: It definitely isn't a timeout issue as I get the error on the client side instantly each time. All other binding config values are matched on both server/client side and set close to max as suggested by other similar issues here on SO.
Hard to tell for sure. To diagnose the issue further, for the service and the client I would enable WCF Tracing and see if there is an underlying exception. Here's a good blog article on how to create and read the log using the tools included with Visual Studio:
http://www.atulverma.com/2011/10/enable-wcf-tracinglogging-using.html
I have a web service that I created in C# and a test harness that was provided by my client. Unfortunately my web service doesn't seem to be parsing the objects created by the test harness. I believe the problem lies with serializing the soap packet.
Using TCPTrace I was able to get the soap packet passed to the web service but only on a remote machine so I can't debug it there. Is there a way of calling my local webservice with the soap packet generated rather than my current test harness where I manually create objects and call the web service through a web reference?
[edit] The machine that I got the soap packet was on a vm so I can't link it to my machine. I suppose I'm looking for a tool that I can paste the soap packet into and it will in turn call my web service
A somewhat manual process would be to use the Poster add-in for Firefox. There is also a java utility called SoapUI that has some discovery based automated templates that you can then modify and run against your service.
By default, .Net will not allow you to connect a packet analyzer like TCPTrace or Fiddler (which I prefer) to localhost or 127.0.0.1 connections (for reasons that I forget now..)
Best way would be to reference your web services via a full IP address or FQDN where possible. That will allow you to trace the calls in the tool of your choice.
Same as palehorse, use soapUI or directly the specific component for that feature: TCPMon.
Just did this the other day with TCPTrace on the local machine. I mapped the remote host in the hosts file to 127.0.0.1. Ran the local web server on 8080, TcpTrace on 80 pointing to 127.0.0.1:8080. Probably your issue is trying to run both at port 80 which won't work.