Wir verwenden Haproxy vor einem von Netty 3.6 ausgeführten Backend. Wir bearbeiten eine Vielzahl von Verbindungen, von denen einige langjährig sein können.

Das Problem ist nun, dass wenn Haproxy eine Verbindung zum Zweck des Neuausgleichs schließt, dies durch Senden eines tcp-RST geschieht. Wenn die von netty eingesetzte sun.nio.ch-Klasse dies sieht, löst sie eine IOException aus: "Connection reset by peer".

Spur:

sun.nio.ch.FileDispatcherImpl.read0(Native Method):1 in ""
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39):1 in ""
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225):1 in ""
sun.nio.ch.IOUtil.read(IOUtil.java:193):1 in ""
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375):1 in ""
org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64):1 in ""
org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109):1 in ""
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312):1 in ""
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90):1 in ""
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178):1 in ""
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145):1 in ""
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615):1 in ""
java.lang.Thread.run(Thread.java:724):1 in ""

Dies führt pro Konfiguration zu folgenden Problemen:

Option http-pretend-keepalive

Dies funktioniert am besten (da Haproxy die meisten Verbindungen mit einem FIN und nicht mit RST zu schließen scheint), es werden jedoch immer noch ca. 3 Ausnahmen pro Server und Sekunde erzeugt. Außerdem wird der Lastenausgleich effektiv neutralisiert, da einige eingehende Verbindungen sehr langlebig sind und einen sehr hohen Durchsatz aufweisen: Mit der Funktion "Pretend Keepalive" werden sie von Haproxy nie auf einen anderen Server neu verteilt.

Option http-keep-alive

Da unser Backend davon ausgeht, dass Keep-Alive-Verbindungen tatsächlich erhalten bleiben (und sie daher nicht von selbst schließen), bedeutet diese Einstellung, dass jede Verbindung letztendlich eine Ausnahme auslöst, die wiederum unsere Server zum Absturz bringt. Wir haben versucht, den Preference-Last-Server hinzuzufügen, aber es hilft nicht viel.

Option http-server-close

Dies sollte theoretisch sowohl für eine ordnungsgemäße Lastverteilung als auch ohne Ausnahmen funktionieren. Nachdem unsere Back-End-Server geantwortet haben, scheint es jedoch ein Rennen zu geben, welche Seite zuerst ihre RST sendet: haproxy oder unseren registrierten ChannelFutureListener.CLOSE. In der Praxis gibt es immer noch zu viele Ausnahmen und unsere Server stürzen ab.

Interessanterweise nehmen die Ausnahmen im Allgemeinen zu, je mehr Arbeitskräfte wir unseren Vertriebskanälen zur Verfügung stellen. Ich denke, es beschleunigt das Lesen mehr als das Schreiben.

Wie auch immer, ich habe jetzt eine Weile über die verschiedenen Kanal- und Socket-Optionen in netty und haproxy nachgelesen und nichts gefunden, was sich nach einer Lösung anhört (oder funktioniert hat, als ich es ausprobiert habe).