Java Polling

Mein Senf:
Ich würde Thread.sleep in einer Serverumgebung tunlichst vermeiden. Ist da einmal die DB langsam und der Client refreshed seinen Browser (was User immer machen, wenn eine Seite nicht kommt -> aber der Server wird dadurch nicht schneller) hast du bald und gerne mal deine "maxServerThreads" erreicht und der Applikationsserver fliegt dir quasi um die Ohren.
Und wenn es trotzdem sein muss, keine Endlosschleife reinprogrammieren. Wir sind bei uns teilweise auch gezwungen, solche sleeps zu coden; Ich empfehle, da einen "Maximale Anzahl Versuche" reinzucoden. Wird der letzte Versuch durchgeführt, ohne entsprechendes Resultat -> PanicException (die haben wir bei uns teilweise wirklich ;P)

Was es neuerdings auch gibt sind WebSockets -> Da wird vom Client zum Server eine bidirektionale TCP/IP Verbindung aufgebaut. Somit kann dann auch der Server dem Client sagen, dass er fertig ist. Ist aber nach meinem Wissensstand als noch bisschen "experimental", vor Allem was Browser und Java-Applikationsserver angelangt (mit Jetty und Aurora-Firefox funktioniert's bei mir)- und produktiv haben wir es nie eingesetzt, kann ich somit nur erwähnen, und nicht empfehlen ;P

Gruss
slowy
 
oder er gibt seinem Clienten noch nen Server und dem Server noch einen Clienten, so das der Server über den Clienten dem Clienten über dessen Server mitteilen kann das er fertig ist
 
Hallo,

...
Mein Senf:
Ich würde Thread.sleep in einer Serverumgebung tunlichst vermeiden. Ist da einmal die DB langsam und der Client refreshed seinen Browser (was User immer machen, wenn eine Seite nicht kommt -> aber der Server wird dadurch nicht schneller) hast du bald und gerne mal deine "maxServerThreads" erreicht und der Applikationsserver fliegt dir quasi um die Ohren.
...
Nur mal so nebenbei, falls das auf mein Beispiel bezogen ist ;-) - ich muss ja irgendwie "Arbeit" simulieren, deshalb hab ich mal ein paar sleeps eingebaut - generell sollte man natürlich kein nicht verwaltetes Threading in einer JEE (Web) Anwendung verwenden - ist ja sonst nicht Spec-Konform...

...
Was es neuerdings auch gibt sind WebSockets -> Da wird vom Client zum Server eine bidirektionale TCP/IP Verbindung aufgebaut. Somit kann dann auch der Server dem Client sagen, dass er fertig ist.
..
Klar das ist natürlich auch eine Möglichkeit und die wird wahrscheinlich in nicht allzu ferner Zukunft immer mehr an Bedeutung gewinnen - dazu braucht man aber auch erst mal einen Servlet Container der das kann (... kann man auch selbst nachrüsten...), bzw. einen Browser der das Unterstützt (es gibt hier Plugins/Extensions jedoch müssen die auch erstmal "erlaubt" sein ;-) )

Gruß Tom
 
Ich habe nichts gegen Thread.sleep, solange es mir meine Applikationsserver nicht kaputtmacht *g* - also HTTP-ThreadPool hat keine Threads mehr vor. (Bin ja Entwickler und "Infrastrukturmanager" oder wie man das nennen will, in einem, und in solchen Situationen haue ich gerne mal auf die Finger, haha).

Als ich mich vor ca. einem halben Jahr oder etwas länger mit den WebSockets auseinander gesetzt habe, war der Jetty nach wie vor der einzige, der das so implementiert hatte, dass es zumindest mal smoke-test mässig funktionierte - kA was passiert, wenn der da 500 permanente Connections hat, zum Beispiel. Und als Browser war das auch nur vom Firefox im Aurorachannel supported (und Chrome, I think,..)

item...
schönen Feierabend =) ... oder vielleicht noch nicht, regnet aus Kübeln

slowy
 
Zurück