Services don't get called after changing its endpoint address in Silverlight under ServiceRefrences.ClientConfig file - silverlight-5.0

I created a Silverlight application, calling services for database connection. I need to deploy this application on to another server. And i made one change in ServiceRefrences.ClientConfig file. I changed the endpoint address to <endpoint address="http://ServerName/Service.svc">from <endpoint address="http://localhost/InsertService.svc"> as the requirement is to access through Servername.
Now the question is, after changing endpoint address from "localhost" to "ServerName", its not working. Services are not getting called and hence fails to connect to Database. Any idea/help/advice on this would truly be appreciated.
Thanks....

The issue was due to i was placing the published folder into different location. http://ServerName/.... was being accessed in d:\ drive while i was copying the folder into c:\ drive. Also it seems the server was accessed by quite a few ppl simulatneously hence due to load it used to take time to call the service, resulting in time-out operation...
I hope the post gets helpful.
Thanks

Related

How can I set TTL for DNS Caching with Delphi SOAP webservices?

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

Suddenly scheduled tasks are not running in coldfusion 8

I am using Coldfusion MX8 server and one of the scheduled task was running from 2 years but now suddenly from 01/12/2014 scheduled tasks are not running. When i browsed the file in browser then the file is running successfully without error.
I am not sure is there any updatation or license expiration problem. I am aware that mid of this year Adobe closed the support for coldfusion 8.
The first most common problem of this problem is external to the server. When you say you browsed to the file and it worked in a browser, it is very important to know if that test was performed on the server desktop. Knowing that you can browse to the file from your desktop or laptop is of small value.
The most common source of issues like this is a change in the DNS or network stack that is interfereing with resolution. For example, if the internal DNS serving your DMZ suddenly starts serving the "external" address - suddenly your server can't browse to your domain. Or if the IP served by the server for the domain in question goes from being 127.0.0.1 to some other IP that the server can't acces correctly due to reverse proxy or LB or some other rule. Finally, sometimes the Apache or IIS is altered so that an IP that previously was serviced (127.0.0.1 being the most common example) now does not respond.
If it is something intrinsic to the scheduler service then Frank's advice is pretty good - especially look for "proxy schduler" entries in the log - they can give you good clues. I would also log results of a scheduled task to a file. Then check the file. If it exists then your scheduled tasks ARE running - they are just not succeeding. Good luck!
I've seen the cf scheduling service crash in CF8. The rest of CF is unaffected.
Have you tried restarting the server?
Here are your concerns:
Your File (works since you tested it manually).
Your Scheduled Task (failed).
Your Coldfusion Application (Service) (any changes here)?
Your Server (what about here).
To test your problem create a duplicate task and schedule it. Leave the other one in place (maybe set your new one to run earlier). Use the same file too. See if it completes.
If it doesn't then you have a larger problem. Since the Coldfusion Server sits atop of the JVM there could be something happening there. Things just don't stop working unless something got corrupted or you got compromised. If you hardened your server by rearranging/renaming the file structure to make it more secure...It would break your task.
So going back: if your test schedule works then determine what is different between the two. Note you have logging capabilities. Logging abilities for CF8
If you are not directly incharge of maintaining this server, then I would recommend asking around and see if there was recent maintenance, if so, what was done to the server?

Dynamically changing config file for Web API does not find service endpoint

I am trying to swap configuration files in and out of my web api to interact with different WCF webservices. I found the solution to change my webconfig files at run time in the following link.
Config Swapper Class
This works great when called from a command line application substituting in my new configuration file but when i call the config file changer from my API I Get the following Error.
"Could not find default endpoint element that references contract 'OldDominionWebServices.RateDelegate' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element."
This is the endpoint I am trying to reference
<endpoint address="https://www.odfl.com:443/wsRate_v4/RateService" binding="basicHttpBinding" bindingConfiguration="RatePortBinding" contract="OldDominionWebServices.RateDelegate" name="OldDominionWebServices" />
I know what the error says, but am unsure as to why this would be thrown in a web api with the configuration file swapped, but not thrown when using a console application that does the same thing. In the case of the command line app the assembly that uses this web service is referenced as part of the solution, where as with the api the assembly is loaded via reflection. I have seen some suggestions that I need to use the Fully qualified domain name in the contract for the endpoint, but this still results in the same error.
I'm hoping this is something simple that I have overlooked, Thanks in advance!
Good question!
Short answer: You can't swap configurations, because web applications use a hierarchy of configuration files that is used in initialization when AppDomain starts, so this would require the restart of AppDomain, and all your in-memory changes would be lost (and this is how that "Config Swapper Class" assembly is intended to work - do everything in memory).
Details:
I did some digging and here is what I've found:
It is not related to the way you load assembly with "Config Swapper Class" assembly, there is nothing there that could be affected by this.
There is no point in restarting AppDomain if your actual configuration lives in memory - all changes would be lost. Probably you could think of another idea of where to store your configuration other than in web.config?
The mentioned assembly (great stuff, BTW!) works in console application, because internally it uses ConfigurationManager, which itself uses ClientConfigurationSystem realization of IInternalConfigSystem interface. Web applications use WebConfigurationManager, that uses other realization of that interface - HttpConfigurationSystem.
So, the "Config Swapper Class" assembly will not help you in web application because it operates on different set of internal classes.

IIS7/.NET web services - Error when one web service calls another

I need a little help solving an issue regarding .NET web services. I have a desktop application that consumes my main web service. One of the methods gets some report data, but in order to do that, web service (A) calls a method in web service (B). Depending what parameters I pass into "A"s method, it either works or fails. If I pass in a filter, the dataset is pretty small, when I don't pass in a filter obviously the dataset is very large. Additionally, if I run web service "A" in debug mode and point my desktop app to the local version (meanwhile B is on our production server), it works wether I filter the data or not. The error I get is a 502 Bad Gateway on production, and a 502 - Web server received an invalid response while acting as a gateway or proxy server.
We have a web farm with some ARR's, so I went into the web farm's ARR, and found "Proxy" settings and adjusted the timeout to 1200 seconds (whereas my app usually fails within 20-30 seconds) and I'm still receive this error. The HTTP version is in "Pass through" mode with the "keep alive" checkbox checked.
We have no issues using a windows service consuming a web service or anything like that, just when one web service consumes another web service.
Addition,
I'm not using any sessions in my web service methods, and I believe the webmethod I call in web service "B" does have a cacheduration value set of 5 minutes.
I'm scratching my head on this for my lack of knowledge of IIS 7, and many other things. If anyone has any ideas or can point me in the right direction I would certainly appreciate it.
I thought I'd come here and answer this question in case anyone else ran into the same issue. This issue was not server related at all. It was code related. In my code I had a datatable (c#), and was doing a datatable.select(....) where I would pass in a filter with many "OR"'s. Ex. Filter = 'x' OR 'y' OR 'z' etc etc. I had around 100 of these, which caused the datatable.select method to produce a stackoverflow exception. I changed the code to do an "IN (x,y,z)" and it works fine now. Hope this helps someone.

VMware Server 2.0 - The VMware Infrastructure Web Service not responding

After installing VMware Server I get the following error when I try to access the VMware web-based server manager:
The VMware Infrastructure Web Service
at "http://localhost:8222/sdk" is not
responding
Go into the services manager and check that the 'VMware Host Agent' service is running. If not, then start it and then try browsing to the site again.
Vmware Hostd was not working for me either.
However, in trying to start the service it stopped automatically. Typically when this happens it is because there is an error in your config.xml.
C:\ProgramData\VMware\VMware Server\hostd\config.xml
In my case, checking the logs at:
C:\ProgramData\VMware\VMware Server
showed it erroring out after "Trying hostsvc".
Searching the config.xml for hostsvc showed references to several things, the first thing was the datastore. In checking my datastores.xml file:
C:\ProgramData\VMware\VMware Server\hostd\datastores.xml .
I found it full of all sorts of random characters instead of a properly formed XML document.
Renaming datastores.xml to datastorex.xml.bad allowed me to start the service. At which point I had to add back my datastores through the GUI.
Hopefully this will help someone else out. I did not find any other references in Google to this issue.
Try accessing via "http://localhost:8222" without the /sdk. You can also try the secure site via "https://localhost:8333".