Okay, I feel I'm pretty good at problem solving but I'm stumped! I can't get connectivity to the SQL Server via the Hybrid Connector or directly.
System Overview:
1x Linux PHP Based WebApp with all the correct SQLSRV libraries working (using a azure sql server I can get the webapp working fine, but need to use our onsite server for the time being)
1x Onsite SQL Server (win2012, sql version 11.0.7), which has an external static IP (and FQDN) and exposed to the internet on port 1433 (I can use SMSS from an external IP to connect and manage the server - with that IP added to the firewall that is..)
So firstly - trying to connect via PHP / SQLSRV directly to the server doesn't work (even if I allow all internet traffic to connect to the server via the firewall) - which is odd as SMSS works. The server is Win2012 and TLS 1.2 is enabled - but I get Error code 0x2746. Investigating this, I think its something to do with openssl 1.1.1 and SQL Server still only using SHA1 - I modified the openssl.cnf file to SECLEVEL=1 - still not dice.
So I've proceeded to setup the Hybrid connections using port 1433 using internal machine name say 'SERVER01' for the endpoint - everything says connected on both the azure hybrid screen and also on the connection manager on the server. I can telnet from SERVER01 to the service endpoint bus and from SSH on the WebApp I can ping the hybrid end point 'SERVER01:443'
But trying to connect to the database from PHP using SQLSRV it timeouts.
Anyone got any pointers? I'm thinking its due to the old onsite server being too old (Win2012) and the SSL SHA1 issues.
I am trying to run the infinispan docker image on a Windows 10 machine with docker desktop for windows.
I wrote a small test Java program that connects to localhost:11222 using hotrod and accesses a cache.
The problem is that after the initial connect the client receives from the server a new address 172.17.0.3:11222 and it fails connecting to this address because this is a docker internal one and
docker desktop for windows cannot route messages directly to an internal container address.
Is there any workaround available in infinispan or on the windows machine ?
The simplest solution is to disable the handling of topology updates in your Hot Rod client:
infinispan.client.hotrod.client_intelligence=BASIC
More information about client intelligence here.
Note that this is not recommended in production: the client will ignore new servers coming up and it will keep trying to contact the servers in the initial server list long after they stop.
I'm trying to create a Test automation Pipeline to run my selenium scripts, I installed Jenkins in windows Remote Server 2012. Used following cmd($ java -jar jenkins.war) to start jenkins. It is working fine in Remote server with url:http://localhost:8080/
But when I'm trying to access it outside Remote server(my local machine) it is not working. am getting error message "This site can’t be reached"
My local laptop and Remote server is under the same proxy org network.
Can someone help how to resolve this issue , so that other folks can access it and run jobs when required from their laptops
Thanks in advance
Access Windows Firewall.
Add an inbound rule to allow port 8080 and
try accessing the url from any machine in the network.
you could allow/restrict access to all IPs, range of IPs or allow all. But to nullify the issue and confirm if its an issue with whitelisting IPs, I'd first allow access from all IPs with the wildcard *
for Debugging if its a port whitelisting issue, you could also telnet from the machine that you are trying to access this machine -
try
telnet remote machines IP Port
note: do not use a colon for port input just use a space
I have together 6 containers running in docker swarm. Kafka+Zookeeper, MongoDB, A, B, C and Interface. Interface is the main access point from public - only this container publish the port - 5683. The interface container connects to A, B and C during startup. I am using docker-compose file + docker stack deploy, each service has a name which is used as host for interface. Everything starts successfully and works fine. After some time (20 mins,1h,..) I am not able to make request to interface. Interface receives my requests but application lost connection with service A,B,C or all of them. If I restart interface, it's able to reconnect to services A,B,C.
I firstly thought it's problem of application so I expose 2 new ports on each service (interface, A,B,C) and connect with profiler and debugger to them. Application is running properly, no leaks, no blocked threads, normally working and waiting for connections. Debugger shows me that when I make a request to interface and interface tries to request service A, Connection reset by peer exception was thrown.
During this debugging I found out interesting stuff. I attached debugger to interface when the services started and also debugger was disconnected after some time. + I was not able to reconnect it, until I made request to the container -> application. PRoblem - handshake failed.
Another interesting stuff that I found out was that I was not able to request neither interface. So I used wireshark to see what's going on and: SYN - ACK was fine. Then application post some data and interface respond with FIN,ACK. I assume that this also happen when interface tries to request service A and it FIN the connection. Codebase of Interface, A,B and C is the same regarding netty server.
Finally, I don't think it's a application issue. Why? I tried to deploy containers not as services. I run each container separately, published the ports of each and endpoint of services were set to localhost. (not overlay network). And it is working. Containers run without problem. + I didn't say at the beginning, that the the java applications (interface, A,B,C) runs without problem when they are running as standalone application - not in docker.
Could you please help me what could be the issue? Why the docker in case of overlay network is closing sockets?
I am using newest docker. I used also older.
Finally, I was able to solve the problem.
What was happening, one more time. Interface opens permanent TCP connection to A,B,C. When you try to run these services A,B,C as a standalone java applications, everything is working. When we dockerize them and run in swarm, it was working only few minutes. Strange was that the connection between Interface and another service was interrupted in the moment when you made a request from client to interface.
After many many unsuccessful tests and debugging each container I tried to run each docker container separately, with mapped ports and as endpoint I specified localhost. (each container exposed ports and interface was connecting to localhost) Funny thing happen, it was working. When you run containers like this, different network driver for container is used. Bridge one. If you run it in swarm, overlay network driver is used.
So it had to be something with the docker network, not with application itself. Next step was tcpdump from each container after couple of minutes, when it should stop working. It was very interesting.
Client -> Interface (OK, request accepted)
Interface ->(forward request because it belongs to A) A
Interface -> A [POST]
A -> Interface [RESET]
A was reseting opened TCP communication after couple of minutes without communication. Why?
Docker uses IP Virtual Server and IPVS maintains its own connection table. The default timeout for CLOSE_WAIT connections in IPVS table is 60 seconds. Hence when the server sends something after 60 seconds, the IPVS connection is no longer available and the packet looks invalid for a new TCP session and gets RST. On the client side, the connection remains forever in FIN_WAIT2 state because the app still has the socket open; kernel's fin_wait timer kicks in only for orphaned TCP sockets.
This is what I read about it and how understand it. I am not sure if my explanation of problem is correct, but based on these assumptions I implemented ping-pong between Interface and A,B,C services in case there is no communication for <60seconds. And, it’s working.
Got the same issue.
Specified
endpoint_mode: dnsrr
to properties of the service which plays "server" role and it works just fine.
https://forums.docker.com/t/tcp-timeout-that-occurs-only-in-docker-swarm-not-simple-docker-run/58179
I've developed a Grails application and I want my coworkers to be able to test it. They are on my network so I figure they can access it by using my IP address and the port number (8080). I've tried running it according to the steps laid out here and here to no avail.
I noticed that whenever I run the program, even when I follow those instructions, it says:
Grails application running at http://localhost:8080 in environment: development
Basic networking stuff here.
When something starts on interface 127.0.0.1 port something
Usually that port is then available for all the interfaces on the machine
if you run netstat -plant you will see running ports open on the machine.
Basically what ever ipconfig or ifconfig tells under Linux as your internal interface something like 192.168.1.x
The app is then available on http://192.168.1.x:8080
If you can't access it from other machines on network start by trying to ping {your machine ip}
It sounds like network security stopping local access from 1 machine accessing another.
Or even better still your good old MS firewall try stopping your security stuff on your desktop
It's not clear if you can access the app yourself on your own machine? It should be available at:
http://localhost:8080/appname
Your co-workers should be able to access the app by changing localhost to your computer name:
http://mycomputername:8080/appname