Wanted to see if zookeeper or curator has any api that can return the host that it was connected to. This is mainly for debugging incase the connection was lost or session was expired we will know which host had the issue. I see CuratorZookeeperClient has a method getConnectionString() but seems like thats just returning the all the hosts in the ensemble.
The ZooKeeper object has the protected method testableRemoteSocketAddress(). It's meant for testing only however. You can create a subclass that adds a method to return the value. Again, for testing only.
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.
in Java, application servers like JBoss EAP have the option to periodically verify the connections in a database pool (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/6.4/html/administration_and_configuration_guide/sect-database_connection_validation). This has been very useful for removing stale connections.
I'm now looking at a ADO.NET application, and I was wondering if there was any similar functionality that could be used with a Microsoft SQL Server?
I ended up find this post by redgate that describes some of the validation that goes on when connections are taken from the pool:
If the connection has died because a router has decided that it no
longer wants to forward your packets and no other routers like you
either then there is no way to know this unless you try to send some
data and don’t get a response.
If you create a connection and a connection pool is created and
connections are put into the pool and not used, the longer they are in
there, the bigger the chance of something bad happening to it.
When you go to use a connection there is nothing to warn you that a
router has stopped forwarding your packets until you go to use it; so
until you use it, you do not know that there is a problem.
This was an issue with connection pooling that was fixed in the first
.Net 4 reliability update (see issue 14 which vaguely describes this)
with a feature called “Connection Pool Resiliency”. The update meant
that when a connection is about to be taken from the pool, it is
checked for TCP validity and only returned if it is in a good state.
I'm a little confused here at the moment. I'm working with Kafka v1.0 and it is being hosted in a VM in the cloud. The single VM hosts Zookeeper as well as Kafka.
I can't seem to get a listeners and advertised.listeners configuration for server properties figured out so I can connect remotely with my producer and consumers.
If I set it like this...
listeners=CLIENT://:9090,PLAINTEXT://:9092
advertised.listeners=CLIENT://:9090,PLAINTEXT://:9092
From my external client I get a NoBrokersAvailable error. If I try this...
listeners=CLIENT://0.0.0.0:9090,PLAINTEXT://:9092
advertised.listeners=CLIENT://0.0.0.0:9090,PLAINTEXT://:9092
I get an error that it can't listen on the meta-address 0.0.0.0.
This is currently being hosted with a public interface, but if I try to set this:
listeners=CLIENT://my.public.dns.name:9090,PLAINTEXT://:9092
advertised.listeners=CLIENT://my.public.dns.name:9090,PLAINTEXT://:9092
Then I get an error that it can't bind to the requested address. This is sitting behind some networking infrastructure, as it's obvious ip addr only shows my private IP address.
How would I get around this to setup a listener so an external/public producer/consumer could connect to this broker?
Thank you in advance!
I am trying to connect to Queue Manager using MQ api and I am able to connect to queue manager
MQQueueManager queueManager=new MQQueueManager(qmgrName);
queueManager.accessQueue(qName,MQOO_OUTPUT);
But when I try to connect to the same queue manager using JMS it fails with 2058 code.Not sure if I am missing something with JMS
MQQueueConnectionFactory qcf=new MQQueueConnectionFactory();
qcf.setQueueManager(qmgrName);
qcf.setPort(1414);
qcf.setHostname("localhost");
qcf.createQueueConnection();
You have two or more queue managers on the local host. In your first example you connect in bindings mode so the queue manager is selected by name and you get the right one. In the second example the connection is being made over a client connection and so is received by the QMgr listening on 1414 which is not the one that you intend so the connection is rejected.
Please note that if both QMgrs have a listener on 1414 the connection will succeed or fail depending on which QMgr was started first. Only one can bind to that port so the first one started on it gets to use it. This might lead to what appears to be inconsistent behavior.
Please see Connection modes for IBM MQ classes for JMS which advises "To change the connection options used by the IBM MQ classes for JMS, modify the Connection Factory property CONNOPT." The acceptable values are provided on the page but you almost always want it to set for Standard Bindings (MQCNO_STANDARD_BINDING).
As documented here, MQRC 2058 means an invalid queue manager name or the queue manager name is unknown. But as you mention, bindings mode connection using MQ Base Java is successful, the queue manager name appears valid.
Update:
Sorry, I was mislead by your code and thought you are trying to do client mode connection using JMS. You don't need to set host and port for bindings mode connection.
Since the transport type is not set, default, WMQ_CM_BINDINGS is used. Suggest you to verify the queue manager name.
To connect with "BINDINGS", the queue manager needs to be local. Are you trying to connect to a remote queue manager? If so you would need to connect as "CLIENT". Also, check to be sure the qmgr is listening on the port you specified.
I set variables host and port instead of setting the 'address' variable tuple in socket.py. I was unable to get 'address' as a tuple to work. I do not believe this is the issue, but I thought I should state this up front.
FYI, my goal is an integrations project, and I believe I isolated socket.py as the problematic code. socket.py is not creating a listener on the remote server. I run the python script on my client, and my server address is 192.168.1.130 port 7879.
I think socket.py is the problem, because I do not receive the expected print statements back through the console that socket.py is attempting to create a socket. In addition, I can RDC to the server, disable ufw (yes I know this is a bad idea), create a tcp listener, push data through the client socket to the server socket, and verify this with netcat.
Am I mistaken that I should be able to parameterize socket.py with nothing more than a host and port and be able to create a socket connection? I am happy to provide more detail from logs, but I thought I should start with a very high level overview.
Answer: More investigation needed. I think socket.py does not create the remote connection with socket(),bind(),listen() statements; instead simply looks for a listener on the remote server with a connect() statement. This is entirely my misunderstanding given I did not dive into the details of the socket.py code. I figured this out because the service running on the remote server creates the listener, but the service itself on the remote server is what is not properly starting.