I am testing out a .NET websocket server on Google App Engine Flexible. As the number of concurrent connections to the server increased I started to see connection failures and 4096 worker_connections are not enough in the logs. I logged into the box and can see that the nginx_proxy container has the following config:
events {
worker_connections 4096;
multi_accept on;
}
Looking through the docs I can see that the PHP Flexible app.yaml has a nginx_conf_override setting but I do not see anything similar for .NET. What are my options for increasing this value?
Update:
I found the following link that suggests I can request an increase from Google Support. I have sent a request and will report back here once I hear a response.
https://issuetracker.google.com/issues/38243437
I heard back from Google support about this issue:
Unfortunately, the NGINX configuration is fixed and cannot be changed.
They did give me some help in temporarily increasing the limit though
Actually, it's possible to change the worker_connections value for one instance SSHing into the VM. Nginx config is located in /tmp/nginx/nginx.conf and you can change it manually on a single VM instance running the following commands.
However as soon as the VM leaves the debug mode or the VM get's killed the changes you've made will be lost:
sudo su
vi /tmp/nginx/nginx.conf #Make your changes
docker cp /tmp/nginx/nginx.conf nginx_proxy:/etc/nginx/nginx.conf
docker exec nginx_proxy nginx -s reload
I used these steps to increase my worker count to 51200 for testing purposes and confirmed my service was able to receive more connections. Unfortunately this won't work for our production release but at least I can run tests while I work out another solution.
Related
Unable to get through the Hybrid Configuration Wizard in Modern mode. This is necessary because we want to migrate mailboxes. Classic mode works.
It knows that there is a Hybrid Agent, but I can't successfully install with either path of using existing or adding a new one. In Azure there is an App Proxy registration which appears to have the incorrect IP for the route to on-prem. This was due to a misconfiguration of our outgoing firewall. However after the firewall configuration was fixed, the App Proxy still has the old return IP, and there is no way in Azure to remove this record.
I've removed the app proxy components on the server, and let the HCW install again but this record is not updated or removed. Also have gone through 'Classic' path which according to community posts is supposed to remove the App Proxy record, but it doesn't.
According to what I've read, if the record is inactive for 10 days, it will be removed, but I'd rather resolve this without waiting for 10 days.
I've tried patching the record using Graph but it doesn't work.
2022.01.31 22:09:59.707 10333 [Client=UX, fn=SendAsync, Thread=15] FINISH Time=2170.2ms Results=BadRequest {"error":{"code":"InternalUrl_Duplicate","message":"Internal url 'https://LOCALFQDNSERVER/' is invalid since it is already in use","innerError":{"date":"2022-01-31T22:09:58","request-id":"d5c4dfe0-096d-4382-9da0-9559f45e0217","client-request-id":"d5c4dfe0-096d-4382-9da0-9559f45e0217"}}}
I'm developing on a shared local server with some other people. This server has one Apache/PHP instance, but then it has multiple "sites-available" (VirtualHost) for different people.
I would like to get XDebug working so every one of us can use it independently. The problem is that if we enable XDebug and, for example, my IDE is connected to the server and I set a breakpoint, it'll stop if other person is browsing the page, even if it's in his/her own VirtualHost.
Any hints on how to properly set this up?
Edit:
Forgot to mention that the webserver is running in Docker.
This is the current configuration of XDebug:
# automatically start debugger on every request
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9000
# send all debug requests to 127.0.0.1
xdebug.remote_connect_back=0
xdebug.remote_host=host.docker.internal
#log all xdebug requests to see is it working correctly
xdebug.remote_log=/var/log/debug.log
Thanks.
This should not happen at all, unless you have xdebug.remote_autostart turned on, and have hard coded xdebug.remote_host (instead of using xdebug.remote_connect_back). You don't want to hard code xdebug.remote_host in a multi-user environment really.
Debugging sessions are only initialised when the XDEBUG_SESSION_START is detected (which is what the browser extension will set, or when that is added to the GET/POST parameters)--and continued requests.
There is also no such concept as:
my IDE is connected to the server
Upon every request, Xdebug (if set to trigger with the cookie) will connect to the IDE. And it uses the xdebug.remote_host setting, or the inferred IP address if xdebug.remote_connect_back is enabled to connect to. And the end of the request, that connection is severed. You can use xdebug.remote_log=/tmp/xdebug.log to create a log file, which will indicate when connections are being made, and whether they work.
I'm setting up SolrCloud 7.2.1 on a Windows Server 2016, following the getting started guide: https://lucene.apache.org/solr/guide/7_2/getting-started-with-solrcloud.html#GettingStartedwithSolrCloud-InteractiveStartup
I have to specify the host because for some reason the SOLR_HOST variable does not have any effect. localhost gets tried all to time.
So specifying the host, everything works fine until a new collection has to be created.
For some reason I get the following error:
ERROR: Failed to create collection 'collectionname' due to: {solrurl:8984_solr=org.apache.solr.client.solrj.SolrServerException:IOException occured when talking to server at: http://solrurl:8984/solr, solrurl:8983_solr=org.apache.solr.client.solrj.SolrServerException:IOException occured when talking to server at: http://solrurl:8983/solr}
I'm a bit puzzled here because I don't understand why it uses HTTP instead of HTTPS.
I can call the URLs with HTTPS without any problems.
When creating a new collection inside the Solr web interface, the same error occures.
SOLR_SSL_ENABLED variable is set to true.
So how can I change this behaviour? Is there anything I have to do beforehand to make Solr accept changes to the solr.in.cmd and solr.in.sh?
If you want to use inter node communcation over SSL, you have to tell Solr to use that first before bringing the nodes up.
You can use the bundled zkcli tool to set the cluster property first:
server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd clusterprop -name urlScheme -val https
It's easy to change the port of the application using the launcher. Go to Edit>>Application Settings (or alternatively Ctrl+i) and change the port. Since I was getting an error similar to the one given below, I changed the application port from 8080 to 48080. Unfortunately, I am not able to change the admin port from 8000 to 48000, because of which I am getting the following error.
google.appengine.tools.devappserver2.wsgi_server.BindError: Unable to bind localhost:8000
I also tried the method illustrated in the following image (my reference being this link):
Regardless of what I try, my web-browsers (Chrome and Firefox) return a message similar to This webpage is not available. Any ideas are appreciated.
I have seen this before, when I had a crashed instance running on the port. You may have a frozen Python script running on that port. On a Mac, I can go to Activity Monitor and kill the process. Not sure if you can do that via task manager in Windows. You may need to restart machine.
We are using the WCF-RIA Services in our project.
On part is a search which will trigger a RIA request on the server.
For this request we have enabled the Client output cache using this attribute:
[OutputCache(OutputCacheLocation.Client, duration: 2 * 60)]
We want to use the client cache, because the information to be cached are user specific. The problem ist, that the cache works fine in Firefox and IE after the application is installed in an IIS, but while debugging IE seems to ignore the caching.
Maybe this is not really a RIA Service specific problem but more of an IE problem. It looks as IE sees "Hey, this is a request to localhost, I don't want to cache that" (some kind of feature).
This is a bit unhelpful, because the debugging situation is not the same as the "live" situation.
Is there a way to use the WCF-RIA Services client cache in IE while debugging?
You should be able to test this using either your machine name in the URL or using localhost. (note the dot at the end) instead of localhost. See here for more info.
Once you have it working with Fiddler you should be able to see if your caching is on or off and debug it.