Progressbar: ALternative zu .dlls = LS2J

[cgorni]

Hallo zusammen,

ich habe schon öfter nach einer Lösung für das Thema ProgressBar gesucht und immer das Übliche gefunden: NotesProgressBar/unsupported/.dll-Aufrufe.

Vor kurzem bin ich über eine Alternative gestolpert, die Java benutzt und LS2J:

http://www.nsftools.com/tips/NotesTips.htm#ls2jexamples

Die Beispielagenten sehen wirklich interessant aus: ein einfacher ProgressBar und eine Erweiterung mit Protokollfenster.

Allerdings habe ich nicht so viel Erfahrung mit LS2J (sprich: keine) und möchte bevor ich das in meinen Agenten standardmäßig einsetze mal nach den Erfahrungen bei euch nachfragen. Irgendwelche Probleme bei LS2J? Auch bei einer so eingeschränkten Lösung wie dieser?

Gruß,
Christian

[Marinero Atlántico]

die Java benutzt und LS2J:

... kündige hiermit für das übernächste Woche ein Mini-Tutorial dazu an wie man mit JProfiler oder vergleichbaren Tools Memory Leaks aufspüren kann. LS2J ist hervorragend für diese Aufgabe ausgestattet:
Wenn ich die Diskussionen auf www.benpoole.com von Dez, Jan sowie die Erfahrungsberichte von Manfred Dillmann richtig verstanden habe, besitzt LS2J das coole feature, dass es quasi automatisch Memory Leaks erzeugt, es sei denn man programmiert sehr komplexen drumherum-code. :-)

Les dir das gut durch:
http://www.benpoole.com/weblog/200501162217#PostComments

[Marinero Atlántico]

Memory Leaks ist quasi das übelste, was eine Plattform an bugs bieten kann.
Nach der Theorie ist ein Fehler desto kostengünstiger zu beheben je früher der Entwickler ihn feststellt.
Manche Fehler fallen schon beim kompilieren auf.
Andere bei Unit Tests.
Wieder andere bei Integrationstest.

Ein Memory Leak ist aber so geartet, dass das System immer mehr Speicher beansprucht ohne diesen freizugeben.
Irgendwann ist der der JVM zur Verfügung stehende speicher voll und es kommt zu einem java.lang.OutOfMemoryError extends java.lang.VirtualMaschineError.
Man muß dann diesen Computer wieder neu starten.
Das hat nix mit Java sondern mit LS2J zu tun.
Damit dies zuschlägt, muß das System eine Zeit laufen (bei Ben Poole waren es 3 Tage). So lange laufen Testmaschinen oft nicht, ohne dass sie durchgebootet werden.
Gemäß meinen Ermittlungen ist dieser fEhler auch nicht irgend so ein fun-Fehler, der schnell mal behoben ist, falls mal einer dazu Bock hat. Nein. Er ist tief verwoben mit dem Garbage Collector Verhalten in jeder Java Virtual Maschine. Ein architektonischer Supergau von Lotus sozusagen.
Profiler Tools wie JProfiler versprechen, dass man mit ihnen solche Fehler frühzeitig erkennen kann. Deshalb das Mini-Tutorial.

Axel

[cgorni]

Hm,

passiert das auch, wenn ich Java-Only aufrufe, d.h. wenn das LS2J-Java selbst keine Domino-Klassen benutzt?

Im Fall der oben genannten Progressbar könnte das der Fall sein (habs noch nicht auf diesen Punkt hin untersucht). Hier werden ein paar Parameter übergeben und ein AWT-Fenster manipuliert.

Gruß,
C.

[Marinero Atlántico]

Hm,

passiert das auch, wenn ich Java-Only aufrufe, d.h. wenn das LS2J-Java selbst keine Domino-Klassen benutzt?

Das ist ein sehr, sehr guter Punkt.
Es könnte gut sein, dass dies dann nicht passiert.
Kenn mich da nicht so aus. Werden dem LS2J-code nicht automatisch Referenzen aus der aufrufenden LotusScript code übergeben?
Muss nicht sein.
Jedenfalls werde ich das mit dem JProfiler mal durchspielen.
Der Zynismus meiner Postings steigt proportional mit dem Stress im Büro. 

Axel

[Ralf_M_Petter]

Hm,

passiert das auch, wenn ich Java-Only aufrufe, d.h. wenn das LS2J-Java selbst keine Domino-Klassen benutzt?

Im Fall der oben genannten Progressbar könnte das der Fall sein (habs noch nicht auf diesen Punkt hin untersucht). Hier werden ein paar Parameter übergeben und ein AWT-Fenster manipuliert.

Gruß,
C.

Hallo!

Diese Frage ist ziemlich irrelevant, da bei LS2J keine Domino Klassen verwendet werden können. Laut Auskunft von Lotussupport ist das ein Sicherheitsfeature???
Übrigens sind mir keine Memory Leaks in LS2J bekannt. Unter Umständen kommt das auf den Anwendungsfall an.

Grüße

Ralf

[Marinero Atlántico]

Und was sollen dann die Punkte 3 und 4 hier?

http://www.benpoole.com/weblog/200501162217#PostComments

[Ralf_M_Petter]

Hallo Axel!

Ich kenne das von Benpoole, aber wie gesagt, ich verwende LS2J auch und hatte bis jetzt keine Memoryprobleme, das heisst natürlich nicht, dass nicht unter anderen Umständen sehr wohl welche auftreten können. Die ganze Thematik der Integration von Java in Notes ist so komplex, dass es schwierig ist, eine konkretes Problem zu verallgemeinern. Was in einer Umgebung wunderbar funktioniert, kann in einer anderen schon wieder Probleme machen.
Deshalb meine Empfehlung nicht per se verteufeln, aber mit einer gesunden Portion misstrauen das ganze betrachten und testen testen testen.

Grüße

Ralf

[Marinero Atlántico]

Hallo Ralf,

hab Hoffnung, dass man dort mit Profilern Dinge sichtbar machen kann.
Poste sobald ich Ergebnisse habe.
Muß mich da aber selber reinwühlen und habe ein generelles Zeitproblem.

Axel

[Manfred Dillmann]

Hallo zusammen,

in meinem Fall war es ein auf dem Server laufender LS-Agent, der via LS2J eine Java-Klasse anspricht und so den Inhalt eines Feeds (also eine URL) abgerufen hat. Axel, der Code ist Dir bestimmt noch grob in Erinnerung - Du hattest ganz am Anfang mal drübergeschaut und den Abruf von Character- auf Bytestream umgestellt.

Wenn dieser Agent auf dem Domino-Server im 5-Minuten-Takt lief, war i.d.R. nach 2 bis max. 3 Tagen Schluss.

Da Christian (cgorni) einen Progressbar darstellen will, wird das wohl auf dem Client im Frontend laufen. Clients werden ja öfter beendet als der Server  und daher sollte diese Art der Nutzung wohl kein Speicherproblem aufwerfen.

Bin aber auf die Ergebnisse von Axel gespannt...

Gruß
Manfred