I use WebRequest in a client to consume a web service on Internet. Each request is triggered in a separate thread.
It works well if hosting the client in IIS. But most of the requests will get timed out error if the client is hosted in a windows service.
When I tried to debug the problem using Fiddler, the WebRequest worked well as all traffic went through 127.0.0.1:8888
Without Fiddler, the traffic goes to Internet directly through a random port, and the time out problem hits again.
The windows service runs under Local System account.
Why do I get time out if the client is in windows service without using a proxy?
Update: My original question wasn't clear. The requests are made concurrently (or at a very short interval). This is to do with the connection limit in the ServicePoint class. By default only 2 connections are allowed to the same external destination. If the destination is local, the limit will be int.Max value. That's why fiddler can magically fix the problem with the proxy. So I manually set the DefaultConnectionLimit to 100 and the requests are on wire.
Adjusting HttpWebRequest Connection Timeout in C#
The most common source of problems that is "magically" fixed by running Fiddler is when your .NET code fails to call Close() on the object returned by GetResponseStream(). See http://www.telerik.com/automated-testing-tools/blog/13-02-28/help-running-fiddler-fixes-my-app.aspx for more details.
Related
I am consistently seeing a 3+ second delay when opening a connection to a Unidata server via OpenAsync and the ADO.NET provider by Rocket.
What can I do to diagnose this delay?
I use jdbc and odbc connections all the time, and three seconds just ain't right.
You can start by breaking things down into client, network, server.
On the client, is it the same if you use an IP address vs hostname? If different, then DNS delay. Do you have any antivirus or other software that might be delaying connections? Can you turn that off, or do a test from a freshly configured machine?
For network, can you ping the unidata server in millseconds? Are there firewalls in the way? Can you install wireshark and filter packets by destination? Is there a delay when you ssh? Is the server configured with LDAP/AD, or local authentication - could be connecting to another server to authenticate?
On the server, you can turn on uniobjects logging, then restart unirpcd. Do you have something in your LOGIN/UOLOGIN that is hanging up the remote connection?
$cat $UDTHOME/serverdebug
udcs 9 /tmp/udcs.log
I have a Delphi Application accessing a web service on the Internet.
The provider of said service has now changed to a cloud based infrastructure and came to me with the following request:
"Please configure networkaddress.cache.ttl in the file $JAVA_HOME/jre/lib/security/java.security as follows: networkaddress.cache.ttl=60"
Accordung to the web service provider this is necessary for the service to deliver correct results under all circumstances.
He has checked the connection of my appication and it appears to him that once started it sticks with the same IP-address.
Restarting the Applications did solve this for once.
I have been importing the WSDL using the wizard provided by the IDE so I am using an instance of THTTPRIO to access the web service.
The THTTPRIO-instance is created in FormCreate() of the main form.
The Application is running 24/7 and accesses several methods of the web service regularly.
Does the Delphi SOAP framwork use DNS caching at all?
If yes, is there a similar property like networkaddress.cache.ttl in Java?
Is there a good workaround for the issue (e.g. reinstancing the wrapper class just before every call to the service instead of only once in FormCreate)?
EDIT:
The Application is compiled using Delphi 10.1. Berlin (originally developed with Delphi XE7). It is running on an Windows 7 machine.
Have you found DnsFlushResolverCache?
In order to clear DNS resolver cache like what IPCONFIG /flushdns
does, programmatically:
Requires dnsapi.dll which requires Win2000 or later. As usual, MS does
not document the API
Source: http://brannockdevice.blogspot.de/2006/04/winxp-flushing-dns-programatically.html
I've been digging into the source code a little and I believe I found an answer.
The Delphi SOAP framwork doesn't seem to do any DNS caching on its own.
It's just that the connection to the web service is done with the first request via the Windows InternetConnect() function and the resulting handle ist stored and reused from then on.
Here's a little more background information on this:
The THTTPRIO class communicates with the web service through an instance of THTTPReqResp:
property HTTPWebNode: THTTPReqResp read GetHTTPWebNode write SetHTTPWebNode;
THTTPReqResp calls the Connect() method before every request which again uses a WinApi function to estabish a connection and stores the resulting handle in a field:
FInetConnect := InternetConnect(FInetRoot, PChar(FURLHost), FURLPort, PChar(FUserName), PChar(FPassword), INTERNET_SERVICE_HTTP, 0, NativeUInt(Self));
But - the Connect() method only does this if it is not already connected - the following code is found just at the beginning of the Connect() method:
if (FConnected) then
Exit;
By doing so the connection just stays open from the first request on.
Following requests are simply using the stored handle from InetConnect.
For my problem with the cloud service it should be sufficient to create my own instance of THTTPRIO and pass it to the function returning the web service interface:
RIO := THTTPRIO.Create(nil);
FM := GetFleetManagerAPISoap(FALSE, '', RIO);
Then I will just disconnect each time before calling any web service function:
RIO.HTTPWebNode.Connect(FALSE);
In theory that should finally lead to a fresh connection via InternetConnect() and hopefully my problem will be solved.
(Still have to test this, though)
I think that you can set it globally in Windows registry.
Open regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
In the right pane, add the following value:
Name: DefaultTTL,
Type: REG_DWORD,
Valid Range: 1-255
Restar the computer.
https://technet.microsoft.com/en-us/library/cc957530.aspx
We provide couple of SOAP web service.
Yesterday our service was down, we couldn't access to the service from the outside (can't even load the wsdl), but we could access to the service if we were connected with terminal service on the server.
The thing is one of our partner was calling our web service with 130 simultaneous threads.
So I think the service was down because this partner was occupying all the available connection. And this limitation is done by .net because I can easily read static file (txt) on my server from the outside, and the service accept the connection if it's from the local IP.
Here is my question : how can I limit the simultaneous connection count for one client ? I know I can do it for every one in IIS Manager, I can do it for outgoing request (connectionmanagement configuration). But I can't find it for incoming request.
It's strange because I think it's one of the first thing I'd set to prevent DOS attack.
(.net 3.5 , IIS 6)
I have a question around biztalk and what happens when certain conditions around web service ports are met.
basically we have two applications - a main application (lets call it 'MainApplication') (containing the orchestration) and a web service application (lets call it 'MainApplicationWS'), where we expose a web service (created from biztalks web service tool) to take messages from wherever.
we have a testing tool which replays messages to the MainApplicationWS to simulate messages coming through from various external systems.
I have noticed that if we partial stop the MainApplicationWS application, and send messages through to the web service listed as a recieve location, nothing happens (obviously!) (also, the web service is still running, even though its been delisted as a recieve location). however, if i start up the MainApplicationWS again and bounce the host instances the messages are picked up from somewhere and played through to the orchestration and through to our application.
Im just a bit puzzled as to where its storing these messages while the MainApplicationWS is partially stopped. is the web service somehow hanging on to these? or does it still post through to the biztalk message box?
any clarification would be greatly appreciated :)
cheers,
adam
In short, I can't repeat your behaviour in Biztalk 2009. The closest to 'queueing' messages is if the orchestration is stopped but remains enlisted, such that messages are suspended resumable.
In long - I'm not quite sure what you mean by 'delisted as a receive location'. In Biztalk 2009:
Receive Locations can be enabled or disabled
Orchestrations can be stopped, and unenlisted
A Partial Stop on your BTS application disables receive ports and stops orchestrations (but doesn't unenlist them)
A full stop stops and unenlists orchestrations
The below is observed behaviour on BizTalk 2009 for a simple orchestration with a WCF Request/Response port, which receives a message, Maps the Send back to the same Port
The port is Direct Bound (MessageBox).
If the Isolated Host App Pool is disabled in IIS
A synchronous error is returned to the client - Standard IIS Error (503 Service Unavailable etc)
BizTalk receives no messages at all
If the BizTalk receive Location is disabled
WSDL: Syncrhonous error returned to the client - The Messaging Engine failed to register the adapter for "WCF-BasicHttp" for the receive location "xyz.svc". Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases
Service Call : The requested service, xyz.svc could not be activated. See the server's diagnostic trace logs for more information.
If the Orchestration is stopped, but not unenlisted
The received message is Suspended, resumable. The client times out (no response is issued).
If the orch is started and the message resumed, the message is then processed. The client will only get a successful reply if the orch start and the suspended message resume are done before the client's configured WS / WCF timeout.
If the Orchestration is unenlisted
The received message is Suspended, not resumable.
The client receives an error - The server was unable to process the request due to an internal error.
With the WCF CustomBinding it is also possible to listen directly on the relevant BizTalk ReceiveHost (i.e. no need for IIS at all to listen to BasicHTTP or WSHTTP, although we generally still use the Wizard generated svc in IIS solely for the hosting and publication of the WSDL. We then create a new WCF Custom receive location directly in BizTalk and point the client to this)
Hope this helps?
Say are dealing with a Windows network that for internet access must pass through a firewall that you have no control over. Said firewall apparently blocks the known time protocols (NTP,daytime,etc) and you know from experience that those who control
it will not allow any exceptions.
Is it possible to sync this "Windows" (could be linux) computer via a web service call which grabs the time from a server out on the internet?
Is there another reliable method for updating time on the server, like pulling from a website and passing it to the ntp client?
HTTP Time Protocol:
http://www.vervest.org/fiki/bin/view/HTP/WebHome
It takes the date from the http server itself, not from a website served by it