MyDAC im Thread = "Net packets out of order"

[Medium]

Hallo!

Ich verzweifle grad an einem Fehler. Wir haben in der Vergangenheit jahrelang ohne Probleme unter D2007 mit UniDAC Threads programmiert, die im Hintergrund regelmäßig ein paar SELECTs ausführen. Jetzt bin ich auf D10.2.3 umgestiegen, wofür wir uns eine entsprechende Version von MyDAC gekauft haben (wir haben nie mehr als diesen Teil der Suite gebraucht, also dieses Mal die kleine Version).

Folgendes Szenario:

Delphi-Quellcode:

type
  TUpdateDataThread = class(TThread)
  private
  protected
    procedure Execute; override;
  public
    FDBInfo: TDBInfo;
  end;

  TSomeClass = class
  // bla
  end;

implementation

procedure TSomeClass.InitThread;
begin
  UpdateThread := TUpdateDataThread.Create(True);
  UpdateThread.FDBInfo := self.DBInfo:
  UpdateThread.Start;
end;

procedure TUpdateDataThread.Execute;
var
  con: TMyConnection;
  qry: TMyQuery;
begin
  inherited;
  con := TMyConnection.Create(nil);
  con.Server := FDBInfo.DBServerName;
  con.Username := FDBInfo.DBUserName;
  con.Password := FDBInfo.DBPassword;
  con.Port := FDBInfo.DBPort;
  con.Database := FDBInfo.DBCatalog;
  con.LoginPrompt := False;
  qry := TMyQuery.Create(nil);
  qry.Connection := con;
  repeat
    try
      CSMasterData.Enter;
      if not con.Connected then con.Connect;
      qry.SQL.Text := 'SELECT foo FROM bar WHERE flump';
      qry.Open;
      while not qry.Eof do
      begin
        // Daten in ein Dictionary packen
        qry.Next;
      end;
      qry.Close;
      end;
    finally
      CSMasterData.Leave;
      Sleep(1000);
    end;
  until Terminated;
  qry.Free;
  con.Free;
end;

Die Connection wird im Thread.Execute erstellt und auch ausschließlich dort genutzt. Das ist definitiv sicher - ist immerhin eine lokale Variable. Dieses Vorgehen setzen wir seit Jahren ohne Probleme unter D2007 ein, and zig Stellen in zig Programmen die seit Jahren 24/7 am Stück laufen. Jetzt unter D10.2.3 mit dem neuen MyDAC bekomme ich sporadisch, und auf unterschiedlichen Rechnern unterschiedlich oft (auf manchen auch fast gar nicht) folgende Fehlermeldungen:

Zitat:

---------------------------
Fehler
---------------------------
ReceiveHeader: Net packets out of order: received[XXX], expected[1].
---------------------------
OK
---------------------------

Wobei das "XXX" irgend eine Zahl ist. Zwischen 0 und 200 habe ich praktisch schon alles gesehen. Sämtliche alte Einträge im Devart Forum beziehen sich auf Nutzung in Threads bei denen die Connection im falschen Kontext erstellt wird. Aber genau das mache ich ja nicht - würde ich mal denken.

Ich komme nicht mehr weiter. Ich habe schon anonyme Threads versucht, abgeleitete wie hier als Beispiel gezeigt, die Connection innerhalb des repeat-until erstellen und wieder freigeben (mit pooling in dem Fall) - nichts. Immer derselbe Effekt. Fällt euch noch was blödes auf?

[Medium]

Ich glaub ich hab's, aber ich glaub noch nicht ganz, dass das zusammenhängen konnte und zu dieser Meldung geführt hat...

Es gibt einen 2. Thread, der durch das o.g. Dictionary geht - nur lesend und zusätzlich durch die CS abgesichert! - und Daten daraus in ein paar Komponenten packt die auf mehrere Frames verteilt sind. Die Komponenten sind von mir selbst, die Setter lösen keine Redraw o.ä. aus, und das in diesem 2. Thread ausgelöste .Paint ist Synchronized.

Was NICHT Synchronized war, waren die

Delphi-Quellcode:

MyFrames[i].BeginUpdate;

und

Delphi-Quellcode:

MyFrames[i].EndUpdate;

Aufrufe drum herum. Die habe ich mal auf gut Glück synchronized, und... seit dem kam der Fehler selbst auf dem PC, der ihn quasi sofort und jede Sekunde brachte, nicht mehr. Seit fast einer Stunde jetzt.

Wie DAS den low-level Netzwerkverkehr der MyDAC Komponenten in einem an diesem Vorgang komplett unbeteiligten Thread-Kontext verwürfeln kann - Da hab ich nicht den Ansatz einer Erklärung für.


Ich betrachte das daher mal als gelöst, aber warum es gelöst ist, kann ich nicht sagen. Mal davon abgesehen, dass die Begin/End-Update Aufrufe klar synchronisiert gehören und das definitiv ein Fehler war. Nur passten weder Effekt noch Meldung im Ansatz dazu, und haben mich jetzt über Wochen auf falsche Fährten geführt. Sowas erklär mal Kunden :D