Normal
nun ... zunächst sind einzelne Threads pro Client bis einige 1000 threads kein problem ... allerdings muss man dafür der VM schon einige resourcen bereitstellen (über cli-parameter) ... aber auch hier ist irgendwann die grenze erreicht denn das system muss ja die unzahl an threads koordinieren ...ein ThreadPool hingegen hat eine feste anzahl an Threads die wiederverwendet werden ...der unterschied besteht hier das halt nicht für jede verbindung sofort ein neuer client-thread gestartet sondern automatisch auf den nächsten freien thread gewartet und dieser dann wiederverwendet wird ...damit ist dann das system nicht ganz so beansprucht da weniger verwaltungsaufwand für eine unzahl an threads draufgeht sondern nur entsprechend der kernzahl ein sehr geringes vielfaches davon verwendet wird ...das problem was sich daraus zwangsläufig ergibt ist die sequenzierung ... also das nicht mehr 1000 clients GLEICHZEITIG (was ja so eh nur "theoretisch" wäre) sondern halt immer nur soviele wie es threads im threadpool gibt ... und der rest wird dann hinten dran gestellt und muss warten bis die resourcen wieder frei sind ...in wie weit das jetzt auswirkungen auf long-time ops hat und damit eventuelle socket-timeouts weis ich nicht ... wäre aber auf jeden fall ein punkt bei dem man sicher weiter erkundigen müsste ...die andere möglichkeit wäre noch NIO ... aber da müssten dir andere helfen ... habe davon keine ahnung
nun ... zunächst sind einzelne Threads pro Client bis einige 1000 threads kein problem ... allerdings muss man dafür der VM schon einige resourcen bereitstellen (über cli-parameter) ... aber auch hier ist irgendwann die grenze erreicht denn das system muss ja die unzahl an threads koordinieren ...
ein ThreadPool hingegen hat eine feste anzahl an Threads die wiederverwendet werden ...
der unterschied besteht hier das halt nicht für jede verbindung sofort ein neuer client-thread gestartet sondern automatisch auf den nächsten freien thread gewartet und dieser dann wiederverwendet wird ...
damit ist dann das system nicht ganz so beansprucht da weniger verwaltungsaufwand für eine unzahl an threads draufgeht sondern nur entsprechend der kernzahl ein sehr geringes vielfaches davon verwendet wird ...
das problem was sich daraus zwangsläufig ergibt ist die sequenzierung ... also das nicht mehr 1000 clients GLEICHZEITIG (was ja so eh nur "theoretisch" wäre) sondern halt immer nur soviele wie es threads im threadpool gibt ... und der rest wird dann hinten dran gestellt und muss warten bis die resourcen wieder frei sind ...
in wie weit das jetzt auswirkungen auf long-time ops hat und damit eventuelle socket-timeouts weis ich nicht ... wäre aber auf jeden fall ein punkt bei dem man sicher weiter erkundigen müsste ...
die andere möglichkeit wäre noch NIO ... aber da müssten dir andere helfen ... habe davon keine ahnung