Hi there,
I love this component.
It is exacly what i was looking for.
There is only a couple of issue that i have to work to fix in order to get it working on my environment.
As documented by Outsystems, in order to properly access the front-end server in the cloud environment, we got to use the public address wich is composed by the server name + .outsystemsenterprise.com.
https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Allowlist_your_OutSystems_cloud_environments_on_your_firewall
So i've changed the extension to use the following code:
PS.: I believe that the component should preferably check the parameters table to confirm it is running on a cloud environment before testing this address.
Currently the extension instantiates a HttpClient for each of the probe requests, which could lead to socket exhaustion as pointed in the following article.
https://www.aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
I've created a static instance of the HttpClient to be reused by all requests in the extension:
Thanks for the great component.
Cheers.
Thanks Matheus.
I have updated the forge component with your suggestions. The final solution I went with was to extract the "outsystemsenterprise.com" from the DNS name, reducing the assumptions we are making about where the server is hosted. And the same code will hopefully work on other scenarios as well.
Hi @Leonardo Fernandes ,
Frankly, I'm not really familiar with the dotnet and not sure how things are done inside the extension.
I'm using this warmup forge in my enterprise env and the problem here is the warmup timer used to work only on the server which the timer is hosted. There's three active front-end servers and It needs to be warming up in all.
What I want to know is do I need to customized the extension in order to meet my requirements or the forge itself is already supported to work on all of the active front-end servers?
Hi Matheus.
Thanks for your feedback. I have a few questions back to you, if I may?
1. I have checked on an enterprise environment with multiple front-ends, and probing by IP works in that case. So what is the scenario that requires using the domain name explicitly?
I am somewhat afraid to just assume the server is hosted in outsystemsenterprise.com - if that assumption doesn't hold, we will be making a request to a different server, and that can create some security concerns for the component.
2. I found that I used HttpClient for probing, and HttpWebRequest for warming up. I don't know why I am using two different methods... But my question is if HttpWebRequest is also susceptible to the same connection leak issue?
I will change the extension to use the same solution in both places, and if HttpWebRequest is good enough then I'll use that. Otherwise I will use a single HttpClient like in your solution.
1. It didn't work in our enterprise environment.
When we tried to make the REST to the specific server through the IP address, we would face the error "HTTPS connection required" resulting and "403 Forbidden" (we've tried using http and https).
Bear in mind that we do have a VPN established with the server.
I would've assume that the following query would be able to verify if it is a cloud environment:
I not aware of any methods to assure that the environment is enterprise. But in case there isn't a way to check it, i think that the component would need a SiteProperty (maybe something like 'IsEnterpriseEnvironment') to enable it.
2. As far as i'm aware, HttpWebRequest doesn't have the same socket exhaustion behavior as the HttpClient.
I personally prefer the use of the HttpClient, since it has a more modern and standard API.
But the HttpWebRequest can be used just fine in case you want to.