Sounds like we need to add a feature to the ChangesBrowser to look at bytecode differences

John

zunächst mal gebe ich Dir Recht: eine Lizenz, die mich einen anfangs schwer zu kalkulierenden Jahresbetrag kostet, ist nicht attraktiv. Man sollte da einfach mal vorab versuchen, eine Kalkulation aufzustellen, wie hoch die Gebühren pro Jahr bei geringem oder großem Erfolg sein werden.

ABER: meines Wissens hat GemStone (tschuldigung, GemTalk) dieses Modell nicht.
Auf der Seite zu den Preisen von GLASS bzw. GemStone/S beziehen sich nach meinem Verständnis die Prozentwerte nur auf einen erweiterten Support, der über mehr als 9 Stunden an 5 Werktagen hinausgehen soll. Ansonsten sind die Preise pro CPU-Core (ich lese das nicht als eine Jahresgebühr). Ob diese Preise allerdings noch gültig sind, weiss ich nicht, auf der neuen Firmen-Homepage sind (zumindest bisher) keine Preise zu finden. Ich nehme aber an, dass sich das bewährte Modell nicht ändern wird. Dennoch sind die Preise stolz, die GemTalk bei höheren Speichermengen und Cores verlangt. Ich bin mir nicht sicher, ob die USD 7000 pro Core nur ab dem 3. core zu bezahlen sind, also bei 4 Cores 14000 USD fällig werden oder nicht. Aber nochmals explizit: die 18 oder 25% jährliche Supportgebühr sind optional, wenn man verlängerte Supportzeiten wünscht. Vermutlich wünscht man diese bei entsprechend großen Installationen. Aber auch dann bezieht sich die Prozentzahl sicherlich nicht auf den Umsatz des Kunden, sondern auf den Kaufpreis.

Also bei 4 Cores kostet die Lizenz dann vermutlich einmalig 14000 USD, und der Support 18% daraus pro Jahr, also 2520 USD p.a. Das erscheint mir nicht allzu schlimm, wenn ich mal einen Web Service anbiete, der 4 Cores braucht und volle 2 GB RAM belegt…
Wie sich die Kaufpreise für Updates gestalten, weiss ich nicht.

Bei GemStone ist sicher ganz wichtig, zu erwähnen, dass die Free Web Edition mit bis zu 2 GB RAM (wohlgemerkt, die DB-Größe ist unlimitiert, es geht nur um die Größe des Page Cache!) und maximal 2 Cores auch für den kommerziellen Gebrauch komplett Kostenlos ist. Damit kommt man sicher schon recht weit.

Die Modelle von GemTalk und Cincom sehen für eine kleine Firma mit 1 bis 5 Entwicklern erst mal unattraktiver aus, aber auch bei Instantiations geht die jährliche Supportgebühr (Support und Updates) für 10 oder mehr Entwickler in ähnliche Regionen wie GemStone. Also auch da muss man einfach eine Kalkulation aufmachen. Bei GemStone hängt der Preis von genutzten Cores und RAM ab, bei Istantiations von der Anzahl Entwickler.

Bei Cincom hat man das Problem mit so und soviel Prozent des mit Smalltak generierten Umsatzes und leider auch bei Gemstone/S. Im Endeffekt müsste man an beide Zahlen und das sind insgesamt mehr als 20 % vom Umsatz (so ungefähr), was ich einfach auch ungerecht finde.. Es ist unheimlich schade, man stelle sich vor man kann Gemstone/S und Cincom Smalltalk benutzen wie man möchte, zahlt seine jährlichen Gebühren und “gut” ist.

Vielleicht ist das aber auch das Erfolgsmodell der beiden, wer weiß….

vielen Dank für die ausführlichen Hintergrundinfos. Das macht natürlich irgendwo Sinn: man stellt sich schon mal am Port an, und wartet, bis man zum Zuge kommt, also derjenige, der aktuell alles Pakete entgegennimmt, damit aufhört.

Natürlich würde dann aber bei dem WASstServerAdaptor noch fehlen, dass er sich auch wirklich aktiv anstellt und lauscht, bis was zu ihm durchdringt. Oder aber, dass er immer wieder mal versucht, sich in den aktiven Zustand (isRunning=true) zu versetzen. Soweit ich das sehe, ist das beides nicht der Fall. Ersteres mag technisch nicht möglich sein, letzteres sicher schon.

Dass das aber nicht passiert, lässt sich in einem VAST-Entwicklungsimage sehr einfach nachvollziehen: man startet zwei (oder mehr) Adapter auf dem selben Port und schaut sich mal an, wie sich die Sache im Seaside Control Panel darstellt. Einer ist grün (isRunning = true) , der andere rot (isRunning = false). Stoppt man nun den laufenden, wäre es sinnvoll, der andere würde das merken und sich aufschalten. Er bleibt aber Rot und ein Webbrowser bekommt auch keine Antwort vom VAST-Image.

Aber ich erwarte soviel highly sophisticated Zeugs gar nicht. Ich möchte ja nur, dass mein Server startet, oder aber, wenn er nicht auf Anfragen antworten kann, sich gleich wieder beendet und mir entsprechende Log-Meldungen ausgibt. Dann kann ich mich kümmern und nach dem Rechten sehen. So, wie es jetzt ist, muss ich stets per Web-Browser und einer entsprechenden Seaside-Komponente nachprüfen, ob denn der alte oder der neue Stand aktiv ist. Ich weiss, auch das lässt sich automatisieren mit CURL und so weiter, aber es bringt eben immer noch mehr bewegliche Teile ins Puzzle…

Naja, meine Umgehungslösung scheint zu funktionieren, und ich hoffe, man denkt bei Instantiations auch ein bisschen darüber nach. Seaside ist ja – zumindest in VAST – noch ziemlich jung.

Joachim

Nach allem, was ich da gelesen habe, scheint mir die sinnvollste Lösung die zu sein, einfach einen http-request durchzufuehren und die Antwort entsprechend zu checken/definieren, so dass man sicherstellen kann, dass es aus der aktuellen VA Instanz kommt.

Wenn dann natuerlich Load-Balancing dazukommt ….

Anscheinend sollte man (ich bin da sehr vorsichtig, denn es gibt verschiedene Szenarien) beim ersten Versuch, den Socket ohne reuse binden – das fuehrt entweder sofort zum Fehler oder man hat den Port.

Problematisch wird das in dem Fall, wenn der Socket einfach noch nicht freigegeben ist und das kann passieren, obwohl ein eventuell vorheriger Serverprozess sich bereits beendet hat.

Im obigen Versuch, würde die neue Instanz kein Bind beim Chance haben – und man muesste die Anwendung immer wieder starten – bis es funktioniert und das kann durchaus “lange” dauern (2 Minuten ? – hat auch was mit dem Verhalten der Clients zu tun).

Um diese Situation zu vermeiden, benutzt man die Reuse Option – die Anwendung kann dann zwar bereits ein bind durchführen, aber unter ungunstigen Umständen kann es Probleme geben.

Microsoft sieht in reuse ein grosses Tor fuer malware, denn ein Prozess kann ohne grosse Security ein bind mit resuse durchfuehren – und wenn der Hauptprozess sich verabschiedet, hat die Malware den Port. Ein weiterer Prozess mit resuse option kommt dann übrigens nicht mehr durch. Man kann nur 1x mit resuse binden.