Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Error cleaning up agent threads und WeakReference...

<< < (7/19) > >>

Mark³:
irgendwie bin ich zu blöd für die Socket-Geschichte...

Ich habe nun einen Server, der bei einem eingehenden Aufruf einen Clientthread startet, den ich von einem Notesagenten starte. Leider klappt der Ablauf Client schickt was, Server antwortet irgendwie nicht.

Im Clientthread lese ich den InputStream mit

--- Code: ---StringBuffer sb = new StringBuffer(255);
int c;
while ((c = in.read()) != -1) {
sb.append((char) c);
}
--- Ende Code ---
Dies ist komischerweise eine Endlosschleife wenn ich vom Client aus dies sende:


--- Code: ---String s = "argument1#argument2";
out.write(s.getBytes());
--- Ende Code ---

Wenn ich aber out.close() mache dann läuft mein ClientThread weiter  ???
Zum parsen zerlege ich den StringBuffer.ToString mit dem StringTokenizer. Beim Prüfen der Werte .equals etc hänge ich auch noch fest  >:D >:D >:D

Evt. fehlt


--- Code: ---out.write('\r');
out.write('\n');

--- Ende Code ---
bei meinem Client?

Ralf_M_Petter:
Hallo Mark!

Warum arbeitest du nicht wie in dem Tutorial mit Readline? Im Tutorial ist doch genau deine Anwendung beschrieben. Du brauchst Sie nur herunterladen und die KnockKnock Protocol Klasse abändern. Am einfachsten wäre es wenn du als Kommunikation unr die Universal ID's der Dokumente schickst die überarbeitet werden und du diese dann in deinem Server abarbeitest.

@Axel. Für mich ist Tomcat für so eine mini Sache auf jeden Fall zu groß. Das ganze soll ja dann auch noch perfromant laufen und nicht unbedingt HSP Ende nie fressen. Ausserdem ist so ein kleiner Client viel leichter zu deployen und birgt auch nicht das Risiko, dass ich mir Sicherheitslücken einfange die irgendwo im Tomcat stecken.

Grüße

Ralf

flaite:
Welche Sicherheitsprobleme?
Man braucht den Server ja nicht gegenüber dem Internet zu öffnen und ausserdem hat doch gerade Tomcat eine Menge an Sicherheitsmechanismen wie Authentifizierung, Autorisierung, SSL, uvam bereits implementiert.

Und wie sicher ist bitte der selbstgeschriebene Server?
Es ist doch eindeutig schwieriger dort Sicherheit zu implementieren.

Also so blöd finde ich die Idee mit Tomcat (oder Jetty) gar nicht. Wie gesagt: Beides kann in eine Anwendung embedded werden.

flaite:
Hab jetzt die KnockKnock Plattform mit Hilfe von Eclipse implementiert.
Ist einfach.
Die 3 Dateien KnockKnockServer, KnockKnockClient und KnockKnockProtocol in 1 Projekt kopieren und kompilieren.
In KnockKnockClient muß man noch die Zeile
kkSocket = new Socket("taranis", 4444);
in
kkSocket = new Socket("127.0.0.1", 4444);
umändern.
Oder dein Server kann per http mit taranis angesprochen werden :-)

Dann die class Datei von Client irgendwohin exportieren.
Den Server in Eclipse starten (geht natürlich auch im debug modus).

Den Client auf der Festplatte von der cmd box aus starten.
Dann wie beschrieben in der Sun Doku.

In jedem Fall ist das Protokoll zu kompliziert. Du benötigst vermutlich nur einen einfachen Command (mit Parametern), der von Notes an den Server geschickt wird und dann schickt der Server die Antwort runter. Die naivste Lösung wäre:
-> Name des Command und jeder Parameter als String, getrennt durch (z.B.) ~. Geht mit Primitivtypen und Strings problemlos. Besser sind imho serialisierte Objekte.

Wenn ich das jetzt richtig verstanden habe, dann verwendet Mehran Habibi in seinem Buch zu Sun Java Dev Examen ein serialsiertes Command Objekt. Dieses wird vom Client an den Server geschickt. Und ich denke, dass dies ein vernünftiger Ansatz ist. Kommt bestimmt noch was von mir zu, wobei ich nicht weiss ob noch heute abend.

Zumindest zeigt das sun beispiel wie es geht. Es ist aber z.B. nicht multithreaded. D.h. es kann immer nur eine Sitzung zu einem User aufmachen. Auch dafür gibts bei Mehran Habibi eine Lsg.

Gruß Axel




Ralf_M_Petter:
Hallo Axel!

Zur Ergänzung, in dem Tutorial ist auch der Link auf den Multithread source.

Grüße

Ralf

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln