INVESTOX-Forum

Hallo Frieder

Klar, der Teil mit der TWS klappt. Aber die Frage war, wie es mit dem IB Gateway und dem Secure Device funzt - und ab einer bestimmten Anzahl Investox Instanzen geht es halt leider nicht mehr nur mit der TWS, man muss ein- oder mehrere Gateways dazu starten. Mit den geschilderten Problemen.

Oder treten diese Probleme bei Dir trotz IB Gateway Verwendung nicht auf? In dem Fall, wie oft in der Woche restartes Du die Gateways? Hängt RTT/IB bei Dir an einem Gateway?

Hallo Bernd, hallo Frieder,

danke für eure Antworten!

- Gateway hängt bei mehreren Inv. Instanzen nach einer Zeit.
Soweit ich die Diskussion hier im Forum verfolt habe gab es mit der ersten Release, welche das Gateway eingeführt hatte Probleme (Kalli hatte darüber berichtet).
Nach den Update sind diese allerdings behoben. Es wäre deshalb durchaus möglich, dass mittlerweile die technischen Probleme gelöst sind, falls diese auf der IB-Seite liegen..
Bernd, wenn Du gerade einen Test fährst (bitte aktuelle TWS Release verwenden) könntest Du bezüglich des beschriebenen Problems uns ein Feedback geben?
Das wäre sehr hilfreich, denn ich würde gerne meine Infrastruktur ebenfalls auf das Gateway rüberziehen - allerdings nur wenn es ausgereift genug ist.

- Wochenendwartung der TWS:
Hallo Frieder, wie erreichst Du es denn, dass die TWS nicht bis zum Wochenende sich nachts ausloggt?

Zitat von »Bernd«

Dieser Zustand scheint besonders dann einzutreten, wenn an einem Gateway RTT/IB angeschlossen ist.

Zitat von »Bernd«

Just ab diesem WoEnde habe ich 2 Instanzen wegen der Connection-Knappheit der TWS wieder an ein Gateway gehängt. Aber kein RTT/IB, nur 2 Investox Instanzen mit neuen Projekten. Mal sehen, wie stabil das bleibt.

Kann die Beobachtungen von Bernd leider nur bestätigen.
Ergänzend folgende Beobachtungen von mir dazu: ich habe auf Maschine (A) 3 Gateways am laufen. Eine gateway mit Connection zu RTT, 2 ohne.
Der an RTT angebundene Gateway hat spätestens nach einer Woche 800MB annektiert und wird irgendwann instabil bis unnutzbar um am Ende komplett "abzunibbeln".
Ich habe es schon erlebt, dass in diesem Stadium die Datenticks um 5-10 Minuten verzögert ankamen und das Gateway derweil einen kompletten Core belegt hat.
Neustart das Gateways und backfill ab Tagesbeginn und alles war "gut"; Backfill geht aber nicht wenn man viele Titel aufzeichnet wie Bernd.
Die beiden nicht an RTT angeschlossenen Gateways klauen sich mit der Zeit auch immer mehr Speicher, nach 2 Wochen kommen Sie meist so auf 450-500MB.
Beim ersten Starten sind es meist so um die 100MB.

Auf einer anderen Maschine (B) habe ich ein Gateway mit RTT Anbindung laufen, dass auch schon mal 2-3 Wochen durchhält und sich eher wie die oben beschriebenen nicht an RTT angebunden Gateways verhält.

Der Unterschied liegt im Betriebssystem und der JAVA Version:

(A): Windwos 2003 Server x64 Edition, 64 Bit Java
(B): Windwos XP, 32 Bite Java


Um dem Problem ein wenig auf den Grund zu gehen müsste man (sowohl in 32 Bit als auch in 64 Bit Umgebung):
1. Ein Gateway öffnen, über das gar nicht gehandelt wird, dass nur "eingeloggt in der Ecke liegt".
2. Dito aber zumindestens 2 oder 3 investox Instanzen permanent angebunden sind, ohne zu handeln

Leider habe ich nicht genügend Logins um das testen zu können.

Fazit:
Es liegt also nicht ausschließlich an der RTT Anbindung, dass das Gateway sinnlos Memory alloziert und nicht wieder rausrückt, das Verhalten tritt auch auf, wenn man darüber handelt und keine Daten zieht, nur nicht so schnell. Und das nutzen von 64 Bit beschleunigt den Vorgang anscheinend erneut. Alles sehr unbefriedigend.

Hallo Kalli,

Zitat

Der Unterschied liegt im Betriebssystem und der JAVA Version:

(A): Windwos 2003 Server x64 Edition, 64 Bit Java
(B): Windwos XP, 32 Bite Java

Das ist interessant, ich hätte ehr erwartet dass das Problem nicht unter Win 2003 Server auftritt, da Win XP - als Officesystem - nicht für den Dauerbetrieb konzipiert wurde.
Aber Im Grunde ist es auch egal, weil es uns bei der Problembehebung nicht weiterhilft.

Könntest Du schon eine Vermutung äussern ob das Problem auf der IB-Seite oder der Investox-Seite liegt?
Nach deinem Beitrag würde ich auf die IB-Seite tippen... wie siehst Du das?

Wenn ich´s wüßte hat ich´s geschrieben.

Hallo Christian

Zitat von »chris2000«

ob das Problem auf der IB-Seite oder der Investox-Seite liegt?

Ich habe vor noch nicht sehr lange Zeit beide Seiten angefragt zu dem Thema, wie beschrieben.

Dass es zu diesem Problem überhaupt kommt, wollte keiner der beiden Hersteller bestätigen. IB wollte darüber hinaus weitere Logs, um überhaupt etwas weiter zu untersuchen. Leider ist es so: wenn die Logs einmal irgendetwas verwertbares enthalten - ist das Kind hier wieder mal in den Brunnen gefallen und es hat mich echtes Geld gekostet. Nach dem Motto, fahren Sie Ihren Wagen mal an die Wand, und wir untersuchen dann den Schrotthaufen - aber ersetzen werden wir ihn Ihnen natürlich nicht.

Zitat von »chris2000«

Bernd, wenn Du gerade einen Test fährst (bitte aktuelle TWS Release verwenden) könntest Du bezüglich des beschriebenen Problems uns ein Feedback geben?

Vielleicht testet ja mal noch ein anderer User (Du?) an diesem Problem mit und berichtet dann, damit nicht immer die Gleichen ihr Geld verlieren (im Paper sind die Tests ja leider nicht zu machen!) und alle anderen dann von der Erfahrungen profitieren

Natürlich wurde die aktuellste Software Kombination eingesetzt und wird es jetzt wieder - sonst ist das die erste Ausrede der Hersteller. Also ist auch jetzt die aktuellste IB Software hier am Start. Investox ist ja soweiso auf dem neusten Stand, hier Life mit V6.

@Frieder

Zitat von »IRCC«

das kann man ja in dem Program TWSSTART leicht einstellen unter "Konfiguration"....

Christian hatte ja gefragt, wie die TWS bei Dir weiterläuft, und es ging um das Secure Device: Deine Antwort sagt also aus, dass TWSSTART jetzt vollautomatisch am Secure Device vorbeikommt !?!

Hallo Frieder

Ich weiss Deine Antwort momentan nicht richtig einzuschätzen, desswegen frage ich mal sachlich:

heisst das, dass man in TWSSTART Code-Nummern vom Secure Device vorkonfigurieren kann und das nimmt diese dann oder wie schafft die Software es sonst, wie Du sagst, mit Null Problemen 6 Tage die Woche am Login vorbei zu kommen?

TWSStart detektiert das Autologoff Fenster und stellt von AM auf PM um und verhindert damit das Zwangsbeenden der TWS wenn man einmal eingeloggt ist.

Leider läuft das aber nicht auf einem RDP betriebenen Rechner, da das Handling hier im gesperrten Modus wohl nicht funktioniert (zumindestens hab ich´s nicht sauber hin bekommen).

Was mich allerdings interessieren würde Frieder:
Wie verhält sich der Speicherbedarf der TWS während dieser 6 Tage?
Memorybedarf beim 1. Starten?
Entwicklung bis zum nächsten Wochenende?

Hallo Frieder

Zitat von »IRCC«

Warum soll ich mich da also mit dem Gateway rümärgern?

Wenn man nur wenige Investox Instanzen am Start hat, kommt man auch ohne Gateway rum, is klar.

Ergänzend noch zur Frage von Lenzelott:
* neben dem Memory Verbrauch, wie entwickelt sich der CPU Verbrauch während der 6 Tage oder gar darüber hinaus?
* Dazu wäre es noch wissenswert, wieviele Titel von der RTT/IB gezogen werden und
* wieviele Investox Instanzen zur TWS connected sind
* wird Markttiefe verwendet

Möglicherweise ist der Amok-Lauf des Gateways ja auch Last- und Zeit-Abhängig und damit am Ende eher durch die API bedingt, und nicht vom Gateway direkt. Dafür wären diese Infos möglicherweise hilfreich!

Hallo Agathon

Meine geschilderten Erfahrungen weiter oben habe ich mit der Einstellung 768m und z.T. 1024m gemacht. Beim Standard von 512m hat bei mir vor Jahren schon die TWS die Flügel gestreckt. Hatte ich vergessen zu erwähnen.

In den Logs war zu finden, dass
* das (java) Memory komplett abgefüllt war und
* die Garbage Collection hat nichts davon abgeräumt, d.h. es gab in der java virtual machine noch gültige Verweise auf die Memoryblöcke

Sah' für mich nach einem typischen Memory Leak aus; d.h. irgend ein Prozess (der kann intern in der jvm ablaufen oder von aussen über die API Schnittstelle getriggert worden sein, das konnte ich nicht unterscheiden) hat immer und immer wieder Memory Blöcke allockiert und nicht mehr freigegeben.

Ich hatte java auch mit Consol-Window gestartet um zu sehen, ob ich bessere Fehlermeldungen bekomme. War aber dann nur das zu sehen, was auch im Log stand.

Falls jemand mit gutem java KnowHow im Forum mitliesst: gibt es einen Post Mortem Debug oder Dump + Dump-Analyzer für die jvm, mit der man in einem solchen Problemfall die Memory Blöcke untersuchen und gar zuordnen kann, um dem Übeltäter-Prozess auf die Spur zu kommen? Auch ein java Process Explorer, falls es sowas gibt, könnte vielleicht nützlich sein. Einfach um in die jvm mal reingucken zu können, wie die Resourcen im Normalfall verteil sind und wie im Problemfall.

Es müsste sich aber um Stand-Alone Versionen handeln für java Debugger oder java Prozess Explorer (und nein, der Prozess Explorer von sysinternals geht leider nicht, liefert keine Insider Infos aus der jvm). Man kann dieses Problem ja leider nur in Produktion untersuchen, nicht im Paper, und dort kann ich kein JDK installieren.

Eingestreute Stack-Traces im Log waren für diesen Fall nicht sehr ergiebig & IB konnte damit das Problem ja auch nicht nachvollziehen.

Zitat von »Agathon«

Rechtsklick auf IBGateway>Eigenschaften>Ziel
Dort den Standardwert xmx512 auf xmx1024 stellen

Zitat von »Bernd«

Meine geschilderten Erfahrungen weiter oben habe ich mit der Einstellung 768m und z.T. 1024m gemacht. Beim Standard von 512m hat bei mir vor Jahren schon die TWS die Flügel gestreckt. Hatte ich vergessen zu erwähnen.

Hatte ich ebenfalls vergessen zu erwähnen: bei mir auch als Standardwert 768m gesetzt.

Hallo Agathon

Soweit möchte ich nicht gehen:

Zitat von »Agathon«

Da IB aber behauptet nie etwas davon gehört zu haben, wie Bernd weiter oben schreibt, deutet das meiner Meinung nach auf ein Problem unserer Software hin

Man muss sich die mögliche Konkurrenz ansehen: ich denke nicht, dass ein Mitbewerber multiple parallele Connections zum Gateway zulässt; dadurch, dass Herr Knöpfel die Investox Software Instanzen-fähig gemacht hat, haben wir möglicherweise eine Situation, die IB so gar nicht kennt und berücksichtig hat!

Ich habe die IB Techniker auch einmal darauf angesprochen, dass meine verwendete Software Instanzen-fähig ist, als Begründung, warum ich sogar mehr als 3 User-IDs brauche für mein Konto - um multiple Gateway für eine grössere Zahl Instanzen und deren Connections starten zu können. Nun, die waren sehr verwirrt und meinten, eine Software müsste so geschrieben sein, dass sie mit einer Connection auskäme. Was natürlich auch absoluter Quatsch ist.

Also, es gibt die Aussagen von IB - und es kommt immer drauf an, welchen technischen Level der dortige Gesprächsparter bisher erreicht hat. Und es gibt unser Investox - im Zweifel vertraue ich aufgrund der vergangenen langen Zusammenarbeit eher Herrn Knöpfel. Allerdings war da die Aussage, dass das Gateway genau so angesprochen wird wie die TWS - und mit der TWS es ja auch keine Probleme gibt:

nun restartet sich die TWS aber normalerweise jeden Tag, und kommt damit gar nicht in den Zustand wie der Gateway, erst nach 8 oder 10 Tagen mitten in der Arbeit mit dem Memory Leak abzuschmieren!

Hier schliesst sich der Kreis zu Frieder - wenn er es schafft, die TWS eine Woche oder besser 14 Tage stabil zu halten, und das bei seinen 125 Symbols plus Trading - dann kann es fast nicht an der Art und Weise liegen, wie Herr Knöpfel das API verwendet!

Aber auch dann bleibt noch: wie weisst man IB nach, dass sie ein Problem haben ?!? Und leider kann man mit den API Leuten nicht telefonieren. Ich habe es probiert, aber die werden hermetisch abgeschirmt und sind nur per Mail zu erreichen. Das macht die Sache nicht leichter, nur schriftlich kommunizieren zu können! Plus die Logs, die sie haben möchten, und jedes Log wurde mit verlorenem Geld bezahlt, ein Betrag x, den man in der Höhe vorher nicht kennt ... nicht lustig.