Eu tenho feito os truques de IP mais complicados da minha vida antes, então não sou um novato. Agora eu tenho uma situação extremamente estranha.
Eu tenho um sistema que eu repliquei dezenas, senão centenas de vezes, com um servidor de servlet jetty, e estou usando uma versão antiga confiável do org.mortbay.jetty 6.11. Peso muito leve. Executado em JRE-1.5, -1.6, -1.7, -1.8, ... em Windows, Linux, FreeBSD, Solaris, o que você tem. Sem problemas.
Agora, o sistema está funcionando bem no Amazon Linux nesta versão específica.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
104 package(s) needed for security, out of 190 available
Run "sudo yum update" to apply all updates.
[ec2-user@ws ~]$ uname -a
Linux ws.pill.guru 4.14.88-88.73.amzn2.x86_64 #1 SMP Thu Dec 13 18:04:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Se eu apenas clonar o sistema, fazendo uma AMI e depois lançar uma instância, na mesma categoria de hardware (t2.nano, t2.micro). À medida que a instância surge, o servidor é iniciado imediatamente. Nenhum erro no log. Mas apenas algo simples como:
curl -v http://localhost/
simplesmente ficará preso.
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.55.1
> Accept: */*
>
e está preso aqui. Nenhuma resposta. Apenas preso.
Netstat mostra a conexão como ESTABELECIDA.
A porta é 80, e eu uso o método setcap para permitir que essa porta seja aberta, cat /etc/rc.local:
touch /var/lock/subsys/local
setcap cap_net_bind_service=+ep $(readlink -f $(which java))
e /etc/ld.so.conf.d/java.conf é
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-0.amzn2.x86_64/jre/lib/amd64/jli
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-0.amzn2.x86_64/lib/amd64/jli
criado com find /usr/lib/jvm/ -name jli >/etc/ld.so.conf.d/java.conf
O estranho é que, se estou criando um servidor do tipo Java netcat muito simples como este:
import java.net.Socket;
import java.net.ServerSocket;
import java.io.InputStream;
import java.io.OutputStream;
public class SimpleServer {
public static void main(String[] args) throws Exception {
try(ServerSocket serverSocket = new ServerSocket(Integer.parseInt(args[0]))) {
while(true) {
Socket conn = serverSocket.accept();
InputStream in = conn.getInputStream();
byte buffer[] = new byte[1024];
while(true) {
int n = in.read(buffer);
if(n < 0)
break;
System.out.write(buffer, 0, n);
}
}
}
}
}
então funciona direitinho.
Agora você pode dizer: há algo errado com seu servidor jetty. Mostre-me esta configuração. Tente essa atualização do cais eclipe, seja o que for, não, não posso permitir esse tipo de corrida. Prefiro abandonar todo o sistema Linux e ir para o FreeBSD. Mas estou relatando esse detalhe na esperança de que alguém tenha visto um problema como esse e possa dar alguma associação livre. Comente ou responda. Eu voto em você, eu prometo.
E eu volto aqui e me reporto se eu descobrir o que está errado.
PS: sim, é estranho que no EC2 essas conexões estejam mostrando como tcp6 no netstat -d -a -t, mesmo que mostrem endereços IPv4. Mas essa não é a questão. Ele ainda funciona no servidor antigo e falha no clone exato.
PS: agora acabei de mover tudo para o FreeBSD e recebo exatamente o mesmo problema!