I'm busy creating some microservices using the Service Fabric mesh, and these services will be making some calls to external API's.
Im using .net core 2.2.
My interservice communication works fine, all the services can talk to one another, but when i try and make a call to an external API, one thats not hosted on my machine, the connection cannot be made and the call fails.
I have check in Fiddler 4 and i don't see any traffic to the urls i'm trying to call, this happens for both HTTP and HTTPS calls, GET and POST.
EDIT
I'm behind a proxy, and it feels like this could be the reason.
Edit 2
I have determined that this is due to our proxy, when connected to a personal connection, the calls work properly.
Although, when i run the same code and tests froma normal cmd app and not from within a conatainer the call works.
How do i get around this?
Related
We have one WCF Service hosted on IIS and there is an WebApp the calls the WCF Service using BasicBinding.
The Service hangs from time to time, I think after a large number of calls.
Sine we host both the WCF Service and the WebApp, is it possible to check if the WebApp closes the connection with the Service.
I am thinking any tool out of the box.
Answering my own question was never my intention. Anyway, I'v fond a very good tool called TCPView.
https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview
I run in on same Server as my WCf Service and could see the list of all open connections.
Best Ragreds
I have a case where I have to send calls to other service methods from a service method. e.g. I call a service method A.Call1() from my smart client application, then after some operations it sends call to B.Call2() and then Call2 method sends call to C.Call3().
When I send few concurrent hits to A.Call1() then all service methods stuck in IIS most of times and times out, anyone suggest a fix or better design.
I'm using simple HttpBinding, 4.6 .Net Framework with IIS 8.5 and using default throttling settings.
I'm starting up a little code project to learn from the process, but I am not sure what's the best way of communicating between the different parts.
First, I have a pure html/js client where the users need to get live updates frequently.
Secondly, I'm considering having a web api application running to provide data.
Thirdly I have a console application running, that needs to communicate with the web api application.
So I'm thinking about using WebSockets all the way from client->web api->console app, but I have trouble making it work. I can make the console app work as a server, but I can't figure out how to make the web api work as a client, so that when it spins up, creates a connection to the console app, and keeps it open for communication, while it delivers data to the clients upon requests.
I tried with different implementations and I have ended up with SignalR, as it seems like that's what people use today :)
Since I have all these problems getting a connection I am wondering if there are better ways of sending data that fulfills my requirements?
If WebSocket (using SignalR) is the way to go, can you provide some links with working examples? I have tried all the top links from Google with no success ^^
Thanks in advance
Your WebAPI project can act as WebSocket server as well. Check this link that uses an IHttpHandler, but you can also do it in a WebAIP's controller how is explained here : Using WebSockets with ASP.NET Web API
The console application should connect as client, using for example ClientWebSocket class.
WebSockets are persistent full duplex connections, so once the client is connected both ends can push information to the other end.
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
The team I work with has recently migrated from a self hosted setup to IIS hosting of thier web services. The migration went 'smoothly' however we are now seeing some funny behaviour on our server.
If we make a simple request call from our client to our server to get some data from our DB everything works as expected. If we make a call from our client to our server and then the server makes a call to a 3rd party service (hosted off site) then we're seeing a massive increase in response time. A call like this used to take less than a few seconds, since migrating to IIS hosting the response time is over a few minutes.
Has anyone seen this behaviour before? Is it possible that we're having issues with credentials between the IIS hosted server and the 3rd party service?
As long as the bindings haven't changed and you are using the same service identity (i.e. Windows account) then you should get the same performance.
Have you checked whether the service is using static variables and/or multi-threading logic? You could be having resource contention problems with the proxy to the 3rd party service. You'll need to provide more detail about service to get a more specific recommendation.