2017-07-05 7 views
-1

Ich lese große Dateien mit dem folgenden Code und senden Sie den Dateiinhalt über einen TCP-Verbindungspuffer durch Puffer. Am Ende jedes Sendevorgangs fügt der TCP-Kanal ein CRLF-Zeichen hinzu. Ich möchte nicht, dass dies in den Ergebnissen erscheint, wenn ich es nicht hinzufüge.Spring-Integration - TCP Outbound Channel fügt unerwünschte CRLF am Ende jeder Zeile hinzu

 final int BUFFER_SIZE = 65536; 
    long bytesToSkip = 0; 
    byte[] buffer = new byte[BUFFER_SIZE]; 

    try (RandomAccessFile rand = new RandomAccessFile(new File(requestModel.getFilePath()), "r"); 
    ) { 

     rand.seek(bytesToSkip); 
     while ((read = rand.read(buffer)) != -1) { 

      MessageBuilder mb = MessageBuilder.withPayload(buffer).setHeaderIfAbsent(IpHeaders.CONNECTION_ID, connectionId); 
      outMsgChannel.send(mb.build()) 

      buffer = new byte[BUFFER_SIZE]; 
     } 
    } 
    catch(Exceptions .............. 

Beispielausgabe, wo neue Zeile hinzugefügt wird. (Sowohl die Puffer sind enorm. Ich habe nur die Linien genannten Probleme am Ende jedes Puffers verursacht)

Buffer One enthalten

A quick brown fox über den faulen Hund springt

Eine schnelle braune Fuchs springt über den faulen Hund

Eine schnelle braune Fuchs springt über den

Buffer Zwei Enthält

lazy dog ​​

Wenn es keine unerwünschten CRLF ist, dann werde ich nicht die Frage der Einzel bekommen Zeile auf zwei in Ausgabe aufteilen. Ich möchte neue Zeilen nur haben, wo die Datei hat.

+0

Warum liest du zweimal? Sie verlieren * Daten auf diese Weise. Und warum ignorierst du die Lesezählung beim Erstellen der Nachricht? Und ignoriere ich offensichtlich den * bugfffer * beim Versenden der Nachricht? Es kann nicht gesagt werden, dass dieser Code überhaupt funktioniert, geschweige denn, wie Sie ihn beschreiben. – EJP

+0

Ich habe die Frage bearbeitet.Die Fehler, die beim Kopieren des Codes vom Projekt in den Beispielcode auftraten, wurden korrigiert. Zweitens, was bedeutet es, die gelesenen Bytes zu ignorieren? Und bitte nicht so schnell die Frage ablehnen, die Antwort meiner wirklichen Frage war entweder Spring TCP Channel hat das Verhalten von CRLF standardmäßig hinzufügen oder die Antwort war, dass Spring eine Konfiguration bietet, um CRLF am Ende jeder Zeile nicht hinzuzufügen. Stimmen Sie ab, wenn Sie möchten, aber geben Sie auch die Antwort. – learner

+0

Der Fehler beim Ignorieren des Lesezählers bleibt bestehen. – EJP

Antwort

2

Siehe the documentation.

TCP ist ein Streaming-Protokoll; Dies bedeutet, dass Daten, die über TCP transportiert werden, eine gewisse Struktur aufweisen müssen, damit der Empfänger die Daten in diskrete Nachrichten abgrenzen kann. Verbindungsfabriken sind so konfiguriert, dass sie (De-) Serialisierer verwenden, um zwischen den Nachrichtennutzinformationen und den Bits, die über TCP gesendet werden, zu konvertieren. Dies wird erreicht, indem ein Deserialisierer und Serializer für eingehende bzw. ausgehende Nachrichten bereitgestellt werden. Eine Anzahl von Standard (de) Serialisierern wird bereitgestellt.

Die ByteArrayCrlfSerializer, konvertiert ein Byte-Array in einen Strom von Bytes gefolgt von Wagenrücklauf und Zeilenvorschubzeichen (\r\n). Dies ist der Standard-Serializer (de) und kann beispielsweise mit telnet als Client verwendet werden.

...

Sie müssen einen Weg zu wissen, wann die Nachricht vollständig ist - das zugrunde liegende Netzwerk Ihre Nachricht paketieren könnte, so dass es in Stücke empfangen wird.

Die ByteArrayRawSerializer fügt der Nachricht keine Zeichen hinzu; es könnte Ihre Bedürfnisse befriedigen. Wenn es auf der Leseseite verwendet wird, verwendet es den Socket-EOF, um anzuzeigen, dass die Nachricht vollständig ist.

+0

Danke Gary. Ich schätze die Details, die Sie zur Verfügung gestellt haben. Ich habe diese Tatsache sicherlich vergessen – learner

Verwandte Themen