I am trying to send some metrics from an http client to kafka and hence exploring kafka-rest. My client itself uses and needs port 8082. I am trying to change the default port of kafka-rest service to be something other than 8082, but it doesnt seem to accept any changes I make to confluent-1.0/etc/kafka-rest/kafka-rest.properties
Mainly I am not sure if I know the right key to set in this properties file.
I tried simply specifying
port=8085
and/or
listeners=8085
But looking at the code:https://github.com/confluentinc/kafka-rest/blob/master/src/main/java/io/confluent/kafkarest/KafkaRestConfig.java there seems to be no way to override this port. Is this correct?
Appreciate any help in this regard.
You have to add port=8085 (or the port you want) to your kafka-rest/kafka-rest.properties
Add listeners=“http://0.0.0.0:8085“ in /etc/kafka-rest/kafka-rest.properties. port property was deprecated.
Documentation - https://docs.confluent.io/5.2.0/kafka-rest/docs/config.html
Related
I am trying to connect a grpc-c++ client to a grpc-c++ server. I already have a grpc-java client connected with working TLS so the server should be functioning correctly.
However inside grpc-java there is a method when building a channel named 'overrideAuthority'. From the documentation the method
"Overrides the authority used with TLS and HTTP virtual hosting. It does not change what host is actually connected to. Is commonly in the form host:port."
I was attempting to find something similar for the c++ client. However, so far all I have found is a function named set_authority() on the grpc::ClientContext as well as two options used with grpc_channel_args which are GRPC_ARG_DEFAULT_AUTHORITY and GRPC_SSL_TARGET_NAME_OVERRIDE_ARG.
None of these seem to have any effect on the authority at all. The server will always reject the connection with the error
No match found for server name: 0.0.0.0.
P.S. I am aware that I can add it to the common name on the certificate (and I will if I need to). However, if possible I would like to follow the same pattern as the grpc-java client.
GRPC_SSL_TARGET_NAME_OVERRIDE_ARG is the right channel arg. Please take a look at some of the tests https://github.com/grpc/grpc/blob/470a3066c74abc7c2a0a2cab3b35000b27b51af1/test/core/end2end/fixtures/h2_ssl.cc#L133
https://github.com/grpc/grpc/blob/470a3066c74abc7c2a0a2cab3b35000b27b51af1/test/cpp/end2end/xds/xds_end2end_test.cc#L1348
Additionally, if I remember correctly, this log just serves as a warning and does not result in disconnections. Please collect some more verbose logs https://github.com/grpc/grpc/blob/master/TROUBLESHOOTING.md. That might give more hints as to what's going on here.
The standard behaviour for wildfly-17 (and 18) with microprofile-health-smallrye is, that the /health endpoints are published under the management port.
Is there a way to configure it to use a different port?
That behaviour is difficult in some situations (with docker and kubernetes) to open up the management port completely, and make it accessible, for other "machines" than localhost.
Thanks in advance,
Gabriel
Jeff Mesnil answered my thread on the wildfly-user chat -> It is not possible to run health endpoint on application port. WildFly only expose them to the managment port.
Whilst I could not find a direct answer I did have a similar issue myself and implemented a solution.
I added the flag Dswarm.port.offset=100. For my thorntail set up this shifted all the port by 100.
My solution to publish metrics within a docker swarm, where port 9990 is not exposed, was to write a Proxy-Servlet registered under /metrics that returns the contents of http://127.0.0.1:9990/metrics.
That way you don't expose the whole admin panel, but only the metrics part.
I'm interested in applying some spray configuration settings at run time and manually setting the config in the code (maybe this isn't advisable, but in this particular case I'm writing a server that needs to have relaxed-header-parsing set to true since it will be accessed by ipv6 and I haven't found another way to allow a spray server to accept requests while being addressed via ipv6). Is there a way to do this? How?
I am trying to run JBoss(5.1) on remote system connecting it using RDC. Which ever port I try, it's says already in use and throwing java.net.BindException Cannot assign requested address: JVM_Bind
I have tried to change the port using jboss service binding configuration located at below path:
jboss\server\Server_Instance\conf\bindingservice.beans\META-INF\bindings-jboss-beans.xml
I have tried various options like ports-01, ports-02 ,ports-03 and then customizing the default port configurations as well with No luck.
I am just wondering how it is possible that it's not allowing any port whichever I try. One thing I would like to let you know here is that the remote system has 3 different logins and all of the users are using the system.
Appreciated if you can provide me any assistance please.
You can pass the -b ${IPofMachine} to bind to an IP. This will also make it externally accessible. You can do 0.0.0.0 which will bind to all available IP's
Just curious. When developing with Casini development server, one has an infinite number of ports. But, the production servers seem to give a particular importance to port 80.
Has that to do with a technical requirement, a convention, or both? I've checked the web but haven't been able to find a clear response so far.
Thanks for helping.
Many services have specifically-assigned ports This allows users to type, for example http://stackoverflow.com and get the website for SO, without needing to enter a port as well. This isn't a technical requirement; however, using a different port requires the user to know an extra piece of information, which must be entered into the URL every time.
When you connect to a server via TCP/IP you specify particular port you connect to. You do not connect to a server and hope that server guesses which port you would like to talk to.
So in most cases you tell browser to use protocol http, say "http://example.com/" then browser uses default port number assigned to that protocol (http) to connect to server "example.com". In this case port is 80. If for example you specify "https://example.com/" then browser looks for default port for https and then connects to port 443 instead.
So if you do not want to tell to every of your users to specify some non-default port for your service (say "http://example.com:60765/") you better use default one.
BTW there is a way to get port number your service listens to by it's protocol name (by asking a service's host's daemon at port 0) but this method seems to be rarely used (if at all).
See also other answers: default protocol numbers are assigned by IANA
It's a convention: you can use whatever port you feel like. You can look at the evolution of RFCs to see when the convention was official (http://www.faqs.org/rfcs/rfc1700.html)
You can see in the RFC 1060 (http://www.faqs.org/rfcs/rfc1060.html ) that it's the ISO Internet Protocol :)
In a production environment your web server is embedded in a server infrastructure (firewalls, proxies) protecting you against attacks from the internet. In such an environment port 80 is normally open for HTTP traffic. If you use this port there is no need to configure your server infrastructure.